[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Any work on sharing of large multi-page segments?


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Andrew Warkentin <andreww591@xxxxxxxxx>
  • Date: Sun, 15 Mar 2015 02:37:01 -0600
  • Delivery-date: Sun, 15 Mar 2015 08:41:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Has anyone done any work on sharing of large multiple-page segments between domains? The current grant table implementation is unsuitable for this because it only allows sharing single pages and is limited to a relatively small number of entries (and passing large numbers of single-page grant references between domains for a segment might get slow).

I am planning to write a paravirtualized OpenGL impelmentation that will use a ring buffer for commands and shared memory for passing buffers between front end and back end, rather than trying to push everything through a socket as VMGL and Chromium do (using sockets to push OpenGL buffers between VMs on the same machine is kind of ridiculous when you could just use shared memory segments). Something like this pretty much requires the ability to grant multi-page segments. The only other option I could see would be limiting the backend to running on dom0 (so it can use xc_map_foreign_pages), which I don't consider acceptable, since some graphics drivers have issues with running on dom0, and I also want to be able to run the backend on an arbitrary domU (such as a dedicated graphics domain, or passing the graphics card to a Windows domU and having other VMs display through it - that's about the only way that I know of to have Direct3D support under Windows simultaneously with OpenGL on other VMs other than using Wine Direct3D, which is somewhat limited).

Another use of segment grants would be sharing of code between driver domains to reduce memory footprint. I am wanting to put together a Xen system where dom0 is a stub domain (running a single-process embedded OS) that just provides xenstore and starts and stops domains (based on requests from a domU), and there is a separate domain for each driver (based on a cut-down Linux system, and maybe also optionally on the same single-process OS as dom0, with the NetBSD rump kernel PCI drivers ported to it). Since there will be several service domains, using segments to share code between them would reduce the memory footprint somewhat (for sharing kernel code these would presumably require some kind of small bootstrap to map the grant reference).

If nobody has patched Xen to support multi-page segment grants (I couldn't find anything of the sort), I plan to write my own patches. Would there be any major limitations of the current design that would prevent supporting them without a major redesign? I'd like to add support for multiple-page grants in a way that requires as few changes to existing DomU code as possible. Maybe a new hypercall that maps a multiple-page grant so that existing grant-handling code won't break if it attempts to map a multiple-page grant reference, and some kind of "grant length table" to allow domains that use v1 grant tables to grant multi-page segments (for v2 grant tables, a new type flag and entry format could probably be used)?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.