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

[Anthony Liguori <anthony@codemonkey.ws>]

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
> debugging.
>
> 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.

Regards,

Anthony Liguori