[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |