qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn


From: Stefano Stabellini
Subject: Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn
Date: Tue, 2 Nov 2010 04:33:12 +0000
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]