From: Hollis Blanchard <hollisb@us.ibm.com>
To: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Cc: kvm-ppc <kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Anthony Liguori
<aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
kvm <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: large page size virtio issues
Date: Wed, 05 Nov 2008 19:50:34 +0000 [thread overview]
Message-ID: <1225914634.26835.102.camel@localhost.localdomain> (raw)
In-Reply-To: <200811052316.47127.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On Wed, 2008-11-05 at 23:16 +1100, Rusty Russell wrote:
> On Wednesday 05 November 2008 09:14:20 Hollis Blanchard wrote:
> > Hi Rusty, I'm using a patch that changes the Linux base page size to
> > 64K. (This is actually pretty common in ppc64 world, but I happen to be
> > trying it on ppc32.)
> >
> > I'm seeing a problem with virtio. I think at least part of it can be
> > explained by qemu's TARGET_PAGE_BITS=12, and the guest's
> > PAGE_SHIFT=16. The guest allocates the queue, then passes the pfn (pa
> >
> > >> PAGE_SHIFT) to the virtio backend (vp_find_vq()). The backend then
> >
> > calculates the pa as pfn << TARGET_PAGE_BITS.
> >
> > I have to run right now, but quickly changing qemu TARGET_PAGE_BITS to
> > 16 got me a little further but still didn't work. Any thoughts?
>
> I see Anthony hardwired page size into the queue activation ABI for
> virtio_pci. I think that this should be an actual 4096 (or 12) rather than
> depending on guest page size:
>
> virtio_pci.c:247:
> iowrite32(virt_to_phys(info->queue) >> PAGE_SHIFT,
> vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
Actually there's an additional complication: PAGE_SIZE is entrenched in
the layout of the ring structure itself (large "struct vring" comment in
include/linux/virtio_ring.h). Callers of vring_size() demonstrate this
problem.
I believe the vring is split across two pages so that it could be
directly mapped by two untrusted guests: the producer would have RW
access to the descriptors and the "available" fields, while the consumer
would have only RO access. I don't think this is yet implemented; is it
still planned?
It looks like vring_size() et al were carefully written to allow
arbitrary page sizes, so for now I'll assume that a struct vring that is
contained completely within a single guest mapping is OK and work up a
patch.
It's worth noting that the PFN_SHIFT question (in the other thread) is a
separate issue. I could have PFN_SHIFT\x10 but define VRING_PAGE_SIZE=4K
for internal alignment. I'm a little nervous about making PPC the only
arch with VRING_PAGE_SIZE=1K, since that might affect my vring layout in
"unusual" ways if it expands beyond 1K but stays inside 4K.
--
Hollis Blanchard
IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Cc: kvm-ppc <kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Anthony Liguori
<aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
kvm <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: large page size virtio issues
Date: Wed, 05 Nov 2008 13:50:34 -0600 [thread overview]
Message-ID: <1225914634.26835.102.camel@localhost.localdomain> (raw)
In-Reply-To: <200811052316.47127.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On Wed, 2008-11-05 at 23:16 +1100, Rusty Russell wrote:
> On Wednesday 05 November 2008 09:14:20 Hollis Blanchard wrote:
> > Hi Rusty, I'm using a patch that changes the Linux base page size to
> > 64K. (This is actually pretty common in ppc64 world, but I happen to be
> > trying it on ppc32.)
> >
> > I'm seeing a problem with virtio. I think at least part of it can be
> > explained by qemu's TARGET_PAGE_BITS==12, and the guest's
> > PAGE_SHIFT==16. The guest allocates the queue, then passes the pfn (pa
> >
> > >> PAGE_SHIFT) to the virtio backend (vp_find_vq()). The backend then
> >
> > calculates the pa as pfn << TARGET_PAGE_BITS.
> >
> > I have to run right now, but quickly changing qemu TARGET_PAGE_BITS to
> > 16 got me a little further but still didn't work. Any thoughts?
>
> I see Anthony hardwired page size into the queue activation ABI for
> virtio_pci. I think that this should be an actual 4096 (or 12) rather than
> depending on guest page size:
>
> virtio_pci.c:247:
> iowrite32(virt_to_phys(info->queue) >> PAGE_SHIFT,
> vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
Actually there's an additional complication: PAGE_SIZE is entrenched in
the layout of the ring structure itself (large "struct vring" comment in
include/linux/virtio_ring.h). Callers of vring_size() demonstrate this
problem.
I believe the vring is split across two pages so that it could be
directly mapped by two untrusted guests: the producer would have RW
access to the descriptors and the "available" fields, while the consumer
would have only RO access. I don't think this is yet implemented; is it
still planned?
It looks like vring_size() et al were carefully written to allow
arbitrary page sizes, so for now I'll assume that a struct vring that is
contained completely within a single guest mapping is OK and work up a
patch.
It's worth noting that the PFN_SHIFT question (in the other thread) is a
separate issue. I could have PFN_SHIFT=10 but define VRING_PAGE_SIZE=4K
for internal alignment. I'm a little nervous about making PPC the only
arch with VRING_PAGE_SIZE=1K, since that might affect my vring layout in
"unusual" ways if it expands beyond 1K but stays inside 4K.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-05 19:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 22:14 large page size virtio issues Hollis Blanchard
2008-11-05 12:16 ` Rusty Russell
[not found] ` <200811052316.47127.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2008-11-05 19:50 ` Hollis Blanchard [this message]
2008-11-05 19:50 ` Hollis Blanchard
2008-11-05 20:08 ` Anthony Liguori
2008-11-05 20:08 ` Anthony Liguori
[not found] ` <4911FD32.9050301-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-05 20:29 ` Hollis Blanchard
2008-11-05 20:29 ` Hollis Blanchard
2008-11-05 14:06 ` Anthony Liguori
[not found] ` <4911A87A.4010209-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-05 16:32 ` Hollis Blanchard
2008-11-05 16:32 ` Hollis Blanchard
[not found] ` <1225902738.26835.51.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-11-05 17:25 ` Anthony Liguori
2008-11-05 17:25 ` Anthony Liguori
2008-11-05 17:31 ` Hollis Blanchard
2008-11-05 17:31 ` Hollis Blanchard
[not found] ` <1225906304.26835.75.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-11-05 17:33 ` Anthony Liguori
2008-11-05 17:33 ` Anthony Liguori
2008-11-05 17:46 ` Hollis Blanchard
2008-11-05 17:46 ` Hollis Blanchard
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=1225914634.26835.102.camel@localhost.localdomain \
--to=hollisb@us.ibm.com \
--cc=aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.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.