From: rusty@rustcorp.com.au (Rusty Russell)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] virtio: Add platform bus driver for memory mapped virtio device
Date: Wed, 05 Oct 2011 11:40:51 +1030 [thread overview]
Message-ID: <87aa9ggs4k.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1317745002.3158.340.camel@hornet.cambridge.arm.com>
On Tue, 04 Oct 2011 17:16:42 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> Greetings!
>
> > > +/* The alignment to use between consumer and producer parts of vring.
> > > + * Currently hardcoded to page size. */
> > > +#define VIRTIO_MMIO_VRING_ALIGN PAGE_SIZE
> >
> > Really? Shouldn't that just be 4k? I haven't seen the qemu side of
> > this, but it seems weird to depend on the kernel's idea of page size...
>
> Well, the Host doesn't really care now, as it's told what the alignment
> is:
>
> > + /* Activate the queue */
> > + writel(VIRTIO_MMIO_VRING_ALIGN,
> > + vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN);
> > + writel(virt_to_phys(info->queue) >> PAGE_SHIFT,
> > + vm_dev->base + VIRTIO_MMIO_QUEUE_PFN);
>
> And I've just chosen the PAGE_SIZE instead of 4096 following the
> suggestion from your original paper ("Note that there is padding such as
> to place this structure on a page separate from the available ring and
> descriptor array:").
Sorry, I missed that. OK!
> > Note that the seabios/coreboot hackers wanted a smaller ring alignment
> > so they didn't have to waste two precious pages per device. You might
> > want to consider making this an option in the header (perhaps express
> > it as log2, eg. 12 rather than 4096).
>
> 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.
> > > + /* 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.
The absolute maximum is a ring of 32k elements, which is about 850k.
That seems a little excessive, though.
Cheers,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Pawel Moll <pawel.moll@arm.com>
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:40:51 +1030 [thread overview]
Message-ID: <87aa9ggs4k.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1317745002.3158.340.camel@hornet.cambridge.arm.com>
On Tue, 04 Oct 2011 17:16:42 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> Greetings!
>
> > > +/* The alignment to use between consumer and producer parts of vring.
> > > + * Currently hardcoded to page size. */
> > > +#define VIRTIO_MMIO_VRING_ALIGN PAGE_SIZE
> >
> > Really? Shouldn't that just be 4k? I haven't seen the qemu side of
> > this, but it seems weird to depend on the kernel's idea of page size...
>
> Well, the Host doesn't really care now, as it's told what the alignment
> is:
>
> > + /* Activate the queue */
> > + writel(VIRTIO_MMIO_VRING_ALIGN,
> > + vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN);
> > + writel(virt_to_phys(info->queue) >> PAGE_SHIFT,
> > + vm_dev->base + VIRTIO_MMIO_QUEUE_PFN);
>
> And I've just chosen the PAGE_SIZE instead of 4096 following the
> suggestion from your original paper ("Note that there is padding such as
> to place this structure on a page separate from the available ring and
> descriptor array:").
Sorry, I missed that. OK!
> > Note that the seabios/coreboot hackers wanted a smaller ring alignment
> > so they didn't have to waste two precious pages per device. You might
> > want to consider making this an option in the header (perhaps express
> > it as log2, eg. 12 rather than 4096).
>
> 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.
> > > + /* 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.
The absolute maximum is a ring of 32k elements, which is about 850k.
That seems a little excessive, though.
Cheers,
Rusty.
next prev parent reply other threads:[~2011-10-05 1:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 13:47 [PATCH] virtio: Add platform bus driver for memory mapped virtio device Pawel Moll
2011-09-28 13:47 ` Pawel Moll
2011-09-28 13:54 ` Pawel Moll
2011-09-28 13:54 ` Pawel Moll
2011-10-03 23:46 ` Rusty Russell
2011-10-03 23:46 ` Rusty Russell
2011-10-04 16:16 ` Pawel Moll
2011-10-04 16:16 ` Pawel Moll
2011-10-05 1:10 ` Rusty Russell [this message]
2011-10-05 1:10 ` Rusty Russell
2011-10-05 10:06 ` Pawel Moll
2011-10-05 10:06 ` Pawel Moll
2011-10-05 18:57 ` [PATCH v2] " Pawel Moll
2011-10-05 18:57 ` Pawel Moll
2011-10-06 16:50 ` [PATCH v3] " Pawel Moll
2011-10-06 16:50 ` Pawel Moll
2011-10-06 17:13 ` Pawel Moll
2011-10-06 17:13 ` Pawel Moll
2011-10-18 4:09 ` Rusty Russell
2011-10-18 4:09 ` Rusty Russell
2011-10-18 9:44 ` Pawel Moll
2011-10-18 9:44 ` Pawel Moll
2011-10-19 2:57 ` Rusty Russell
2011-10-19 2:57 ` Rusty Russell
2011-10-21 17:57 ` Pawel Moll
2011-10-21 17:57 ` Pawel Moll
2011-10-24 2:33 ` Rusty Russell
2011-10-24 2:33 ` Rusty Russell
2011-10-24 13:06 ` Pawel Moll
2011-10-24 13:06 ` Pawel Moll
2011-10-24 13:07 ` [PATCH v4] " Pawel Moll
2011-10-24 13:07 ` Pawel Moll
2011-10-25 1:13 ` Rusty Russell
2011-10-25 1:13 ` Rusty Russell
2011-10-24 13:07 ` Pawel Moll
2011-10-26 4:06 ` [PATCH v3] " Rusty Russell
2011-10-26 4:06 ` Rusty Russell
2011-10-26 9:54 ` Pawel Moll
2011-10-26 11:50 ` Rusty Russell
2011-10-26 11:50 ` Rusty Russell
2011-10-24 13:06 ` Pawel Moll
2011-10-13 16:49 ` Pawel Moll
2011-10-13 16:49 ` Pawel Moll
2011-10-05 10:39 ` [PATCH] " Michael S. Tsirkin
2011-10-05 10:39 ` 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=87aa9ggs4k.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.