From: Julien Grall <julien.grall@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Qemu-devel] [Xen-devel] Qemu disaggregation in Xen environment
Date: Mon, 12 Mar 2012 13:42:10 +0000 [thread overview]
Message-ID: <4F5DFD32.1020107@citrix.com> (raw)
In-Reply-To: <1330985175.22559.60.camel@cthulhu.hellion.org.uk>
On 03/05/2012 10:06 PM, Ian Campbell wrote:
> I'm not aware of any code existing to do this.
>
> There's a bunch of interesting stuff to do on the Xen side to make this
> stuff work.
>
> Firstly you would need to add support to the hypervisor for dispatching
> I/O requests to multiple qemu instances (via multiple io req rings). I
> think at the moment there is only support for a single ring (or maybe
> it's one sync and one buffered I/O ring).
>
I have modified Xen to create "ioreq servers". An ioreq server
contains a list of IO ranges and a list of BDFs to trap IOs for a
unique instance of QEMU running.
Each ioreq server can be associated to an event channel.
This way we can deliver IOs events to different processes.
For each QEMU, a ioreq server is created. QEMU must specify
which pci (with a BDF) and IO range it handles.
I added some hypercalls:
- to register an ioreq server
- to register/unregister BDF
- to register/unregister IO range
For the moment all QEMUs share the same pages (buffered and
IO request). For more security, I would like to privatize these
pages for each ioreq server. I saw these pages are allocated by
the toolstack. Can we assume that the toolstack know at domain
creation time how many QEMU it is going to spawn ?
> You'd also need to make sure that qemu explicitly requests all the MMIO
> regions it is interested in. Currently the hypervisor forwards any
> unknown MMIO to qemu so the explicit registration is probably not done
> as consistently as it could be. If you want to have N qemus then you
> need to make sure that at least N-1 of register for everything they are
> interested in.
>
I have modified QEMU to register all IO ranges and pci it needs.
All unregister IO is discarded by Xen.
> Currently the PCI config space decode is done within qemu which is a bit
> tricky if you are wanting to have different emulated PCI devices in
> different qemu processes. We think it would independently be an
> architectural improvement to have the hypervisor do the PCI config space
> decode anyway. This would allow it to forward the I/O to the correct
> qemu (there are other benefits to this change, e.g. relating to PCI
> passthrough and the handling of MSI configuration etc)
>
I have created a patch which allow Xen to catch cf8 through cff
io port registers. Xen goes through the list of ioreq servers to
know which server can handle the PCI and prepare the resquest.
For that I added a new io request type IOREQ_TYPE_PCI_CONFIG.
> Then you'd need to do a bunch of toolstack level work to start and
> manage the multiple qemu processes instead of the existing single
> process.
I have began to modify the toolstack. For the moment, I just
handle a new type of device model for my own test.
next prev parent reply other threads:[~2012-03-12 13:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 11:46 [Qemu-devel] Qemu disaggregation in Xen environment Julien Grall
2012-03-05 22:06 ` [Qemu-devel] [Xen-devel] " Ian Campbell
2012-03-12 13:42 ` Julien Grall [this message]
2012-03-05 22:20 ` [Qemu-devel] " Anthony Liguori
2012-03-05 22:53 ` Stefano Stabellini
2012-03-06 1:45 ` Anthony Liguori
2012-03-06 8:22 ` Markus Armbruster
2012-03-06 15:11 ` Anthony Liguori
2012-03-12 13:17 ` Stefano Stabellini
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=4F5DFD32.1020107@citrix.com \
--to=julien.grall@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=julian.pidancet@citrix.com \
--cc=qemu-devel@nongnu.org \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).