On Mon, 1 Nov 2010, Anthony Liguori wrote: > On 11/01/2010 02:47 PM, Alexander Graf wrote: > > Where else would it belong? Qemu is an emulator. Device emulation belongs > > to qemu code. The xen PV machine is nothing but a special case of the pc > > machine with custom firmware and odd devices :). > > > > As I stated in my cover letter, the goal of all this should be to have the > > qemu pieces be 100% independent of any xen headers or libraries, > > I'm not sure I agree with the goal. I think where ever possible we > should reuse code with the Xen project when it makes sense. Reusing > blkback/netback is impossible because we want userspace implementations > and the current implementations are in the kernel. blktap also doesn't > tie into the QEMU block layer and making it tie into the QEMU block > layer would probably result in more code than it saved. > > OTOH, xenstored and xenconsoled have very little direct dependence on > Xen. I'm not saying that we shouldn't make things Just Work in QEMU, so > if that means spawning xenconsoled/xenstored automagically from QEMU > with special options, that's perfectly fine. > > But to replicate the functionality of this code solely because of NIH > seems like a waste of effort. >
I have been traveling so I haven't had a chance to carefully read the series yet, however these are my early observations: I don't mind xenner, of course I think the best way to run a PV guest is to use Xen, but Xenner can be useful in many ways. I would love to see an x86_32 PV guest run on PowerPC, or even in a Xen HVM domain! It would be very useful for testing too, it would shorten my dev & test cycle by quite a bit. I am a strong proponent of code sharing and reuse so I agree with Anthony on this: we should reuse Xen libraries and daemons as much as possible. If you need some patches to port xenstored and/or xenconsoled to PowerPC we would gladly accept them. That said, many Xen components are obviously tied to the Xen architecture, so it might not be easy to reuse them outside a Xen environment. For example: making xenstored work without Xen shouldn't be too difficult but porting libxc to KVM/QEMU I think would be harder. I am looking forward to talking with you in Boston, Stefano
