[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Xen's qemu branches, etc.
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |