From: Andrew Warkentin <andreww591@gmail.com>
To: xen-devel@lists.xen.org
Subject: Any work on sharing of large multi-page segments?
Date: Sun, 15 Mar 2015 02:37:01 -0600 [thread overview]
Message-ID: <550544AD.4040308@gmail.com> (raw)
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)?
next reply other threads:[~2015-03-15 8:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-15 8:37 Andrew Warkentin [this message]
2015-03-16 11:49 ` Any work on sharing of large multi-page segments? Jan Beulich
2015-03-17 0:46 ` Andrew Warkentin
2015-03-17 8:54 ` Jan Beulich
2015-03-17 23:45 ` Andrew Warkentin
2015-03-18 10:16 ` Ian Campbell
2015-03-18 16:40 ` George Dunlap
2015-03-17 11:48 ` George Dunlap
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=550544AD.4040308@gmail.com \
--to=andreww591@gmail.com \
--cc=xen-devel@lists.xen.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.