From: Pawel Moll <pawel.moll@arm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
Anthony Liguori <aliguori@us.ibm.com>,
"Michael S.Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] virtio: Add platform bus driver for memory mapped virtio device
Date: Wed, 05 Oct 2011 11:06:30 +0100 [thread overview]
Message-ID: <1317809190.3158.352.camel@hornet.cambridge.arm.com> (raw)
In-Reply-To: <87aa9ggs4k.fsf@rustcorp.com.au>
> > I had an impression that you were planning to add some API for the
> > devices to choose the alignment? If so this #define would simply
> > disappear... Generally, the Client is in control now.
>
> I'm not sure it makes sense to vary per-device, but per-OS perhaps.
It's sorted then - the Guest implementation chooses the alignment, the
Host is informed about it, everyone is happy :-)
> > > > + /* TODO: Write requested queue size to VIRTIO_MMIO_QUEUE_NUM */
> > > > +
> > > > + /* Check if queue is either not available or already active. */
> > > > + num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM);
> > > > + if (!num || readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN)) {
> > >
> > > Please fix this now, like so:
> > >
> > > /* Queue shouldn't already be set up. */
> > > if (readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN))
> > > ...
> > >
> > > /* Try for a big queue, drop down to a two-page queue. */
> > > num = VIRTIO_MMIO_MAX_RING;
> >
> > Ok, but how much would MAX_RING be? 1024? 513? 127? I really wouldn't
> > like to be a judge here... I was hoping the device would tell me that
> > (it knows what amounts of data are likely to be processed?)
>
> I'm not sure who knows better, device or driver. The device can suggest
> a value, but you should always write it, otherwise that code will never
> get tested until it's too late...
>
> > > for (;;) {
> > > size = PAGE_ALIGN(vring_size(num, VIRTIO_MMIO_VRING_ALIGN));
> > > info->queue = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
> > > if (info->queue)
> > > break;
> > >
> > > /* Already smallest possible allocation? */
> > > if (size == VIRTIO_MMIO_VRING_ALIGN*2) {
> > > err = -ENOMEM;
> > > goto error_kmalloc;
> > > }
> > > num /= 2;
> > > }
> > and then
> > writel(num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM);
> >
> > Can do. This, however, gets us back to this question: can the Host
> > cowardly refuse the requested queue size? If you really think that it
> > can't, I'm happy to accept that and change the spec accordingly. If it
> > can, we'll have to read the size back and potentially re-alloc pages...
>
> I'm not sure. Perhaps the device gives the maximum it will accept, and
> the driver should start from that or 1025, whatever is less (that's
> still 28k for each ring). That gives us flexibility.
Ok, So I'll add sort of "QUEUE_NUM_MAX" read-only register in the device
spec and use min(device_max, driver_max) as a base for the pages
allocation, then notify the Host about the queue size as done with the
alignment.
Patch v2 to follow shortly.
Cheers!
Paweł
next prev parent reply other threads:[~2011-10-05 10:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 13:47 Pawel Moll
2011-09-28 13:54 ` Pawel Moll
2011-10-03 23:46 ` Rusty Russell
2011-10-04 16:16 ` Pawel Moll
2011-10-05 1:10 ` Rusty Russell
2011-10-05 10:06 ` Pawel Moll [this message]
2011-10-05 18:57 ` [PATCH v2] " Pawel Moll
2011-10-06 16:50 ` [PATCH v3] " Pawel Moll
2011-10-06 17:13 ` Pawel Moll
2011-10-18 4:09 ` Rusty Russell
2011-10-18 9:44 ` Pawel Moll
2011-10-19 2:57 ` Rusty Russell
2011-10-21 17:57 ` Pawel Moll
2011-10-24 2:33 ` Rusty Russell
2011-10-24 13:06 ` Pawel Moll
2011-10-24 13:07 ` [PATCH v4] " Pawel Moll
2011-10-25 1:13 ` Rusty Russell
2011-10-26 4:06 ` [PATCH v3] " Rusty Russell
[not found] ` <1319612222.2878.4.camel@rojo>
2011-10-26 11:50 ` Rusty Russell
2011-10-13 16:49 ` Pawel Moll
2011-10-05 10:39 ` [PATCH] " Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1317809190.3158.352.camel@hornet.cambridge.arm.com \
--to=pawel.moll@arm.com \
--cc=aliguori@us.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®