This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: Xen's qemu branches, etc.

Hi Ian,

Ian Jackson wrote:
Because Xen 3.3 is nearing release and currently firmly frozen, both
of these branches are currently based on a few months' old version of
qemu upstream.  I intend to fork off new development branches of both
very soon, and then bring both of them up to parity with a modern qemu
upstream.  One natural output of such a merge process is a number of
patches for upstream.

I'm looking forward to this and appreciate your work here.

It would be very nice to get the differences between qemu in Xen and
qemu upstream down to zero.  There are three kinds of change in our
tree which will prevent this in the short to medium term:

Firstly, there are some things in our tree which are simply too ugly.
We would like to improve them and feed them upstream in due course,
but that's more of a medium to long term project.  A top priority in
this area is display handling.

Secondly, there are changes which are only useful in a Xen context.
An example would be the machinery to monitor `disk change' events
which are injected via the Xen management tools.  This is done in our
qemu by xen-specific code which talks to the xenstore IPC/IDC daemon.
This code is completely Xen specific and depends on the presence of
the Xen management stack, so it must only be compiled in to the
specific Xen device model qemu executable.  We would be happy to have
this code in qemu upstream, but it is quite closely linked to much of
the Xen management toolstack and quite loosely coupled to the rest of
qemu so in practice this is not currently a priority for us.

I think that there is room to discuss these sort of things. I think most of these things will actually fall into the first category where we could add the same mechanism to QEMU (perhaps via the monitor), and then Xen could have a small shim that interacted with both XenStore and the QEMU monitor. But really, this isn't the low hanging fruit so we can cross this bridge when we come to it :-)

There are also another set of concievable things: _emulations_ in qemu
of the Xen environment, so that a Xen PV guest can be run without the
Xen hypervisor and host infrastructure, or so that Xen PV drivers can
be used to improve the performance of a plain qemu guest.

That includes, for example, xenstore/xenbus emulation, Xen PV backend
drivers, and the like.  Gerd's patches contained several such things.

The patch series that Gerd posted has nothing to do with a Xen shim or emulation layer. The PV backends are directly usable by Xen. Now if ya'll want nothing to do with these backends, then I'm inclined to wait to add those backends until they are being used by something before pulling it into QEMU. There's no point in adding code to QEMU that noone is actually going to use.

So that may mean waiting to pull in the userspace net/block backends until Xenner can be merged into QEMU. That seems fine to me.

I think a qemu emulator which can support Xen guests without needing
Xen is in principle a fine and good thing to have in qemu upstream.
We don't have it in our Xen tree because we have the real hypervisor
and dom0-provided backends.  But I'm sure we'd find them useful for

BUT we have to not get confused so the names must be different.

So far, I haven't seen patches on qemu-devel that are for a Xen shim/emulation layer so that doesn't seem like a problem to me. I assume anything related to the shim/emulation layer will be clearly identified as 'Xenner' anyway.

It is necessary to clearly distinguish these two use cases:

 * qemu-dm run under the Xen hypervisor, xend, with xenstore, to
   support Xen guests as currently done in the Xen upstream project

 * qemu emulating the Xen environment

I think these should be given different names.  We should not use
`xen' for both.

To me, this isn't a big issue. Whether we have one or two machine types will be determined by the implementations. What I want to see is as much code sharing as possible for both cases.


Anthony Liguori

Xen-devel mailing list