I thought that following that lovely discussion it might be helpful to
summarise a few things about the way I see things:
As Samuel says, I'm currently maintaining two branches: one contains
code which I would like to get to upstream qemu in the nearish future,
and one which contains changes which I don't think have a practical
chance of going upstream any time soon. (I also have a gaggle of
topic branches of course.)
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.
Once that merge is done I intend, while Xen development is fully open,
to frequently update both my new trees from upstream - say, weekly.
As before, shortly before the Xen freeze I will stop pulling from qemu
upstream.
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.
Thirdly, there are some changes which we have been told are not
suitable for qemu upstream, but which we (Xen) are pretty convinced we
need to retain. An example is the mapcache. (Please don't explain
again why the mapcache is not necessary. That conversation has been
had and we've come to different conclusions, which is fine - this is
Free Software after all, which means that we can work together well,
and hopefully without rancour, even though we sometimes disagree.)
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.
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.
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.
The plumbing involved is quite different. Users will get confused and
the results will be mysterious failures. Developers will get confused
and the results will be people talking and coding past each other.
I would like to suggest that the first of these two options should be
called `xen' or `xen-hvm' or `xen-pv' or `xen-fv' or some such.
Code in qemu intended to support running under the Xen hypervisor and
upstream Xen toolstack should use the name `xen'. This includes (for
example) portability to the Xen minios embedded system, frontend
drivers for Xen PV block and network devices, interaction with
xenstore, interaction with the hypervisor to collect IO requests from
the running guest and return the responses, and so on.
Code in qemu intended to support Xen guests without the use of the Xen
hypervisor and tools should be called `xenemu' or some such. This
includes backend drivers for block and network devices,
xenstore/xenbus emulation, and so on.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home