Hollis Blanchard wrote:
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?
Rusty experimented with it but I don't think anyone has done anything seriously with it.
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 was written that way so that vring_size() could be used in userspace where there isn't a PAGE_SIZE defined. Rusty just passes in getpagesize() in the lguest userspace.
Pure evil if you ask me :-)
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.
This is starting to get a little hairy. Maybe 64k guest pages is asking for trouble? Are you sure other things aren't breaking all over the place with these patches in place?
Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
