Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu

[Anthony Liguori <anthony@codemonkey.ws>]

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 0/7] merge some xen bits into qemu"):
>   
>> Here are a bunch of patches which start adding xen support to qemu.
>> Overview (individual patches have longer descriptions):
>>     
>
> Just to clarify: as far as I can tell from the description,
> this code has scant relationship with Xen upstream.
>
> I'm generally in favour of pushing functionality out of the Xen branch
> of qemu into upstream.  But going by Gerd Hoffman's description I
> don't think that's what his branch is.  His code doesn't appear to be
> related to the Xen branch of qemu that we are using.
>   

I think it's more closely related to Xenite and Xenner.  Gerd: are you 
planning on folding in domain creation?  Right now it appears to be a 
helper launched after the domain creation.

> For example,
>
>   
>> With the first four patches in place upstream qemu can replace xen's
>> qemu-dm for paravirtual domains.  The block and nic backend drivers are
>> full userspace implementations using the grant table device (gntdev).
>>     
>
> we only use qemu-dm in paravirtualised domains for certain marginal
> functions - in many cases it is not used at all.  Certainly the
> functionality Gerd describes, such as xen backend block and network
> drivers, are not in our qemu tree and we do not intend for them to be
> there.
>   

There's no reason they couldn't be though.  It's just like blktap.

> In a Xen installation this functionality is in the dom0 (host) kernel.
>
>
> As far as I can see much of Gerd Hoffman's intended submission is
> effectively an _emulator_ for Xen guests.  That is, it emulates a Xen
> host without being one, so that a Xen domU can be run without the Xen
> hypervisor.  Am I right, Gerd ?
>   

No, it's definitely for use with Xen (hypervisor).  But it's different 
architecturally from how Xen uses QEMU in xen-unstable.

Personally, I really like the way Gerd has the code structured.  It 
seems like it could be used as almost a drop-in replacement for qemu-dm 
for PV guests.  HVM guests would require more work.  Of course, the 
net/disk support can be completely optionally.

With that said, it would be silly to have two Xen implementations within 
QEMU so there has to be some general agreement in the Xen community 
about how QEMU is going to be used before merging would make sense.  
That probably requires some discussion about how the HVM support would 
fit into this architecture.

Regards,

Anthony Liguori



> I don't think there's anything wrong with that from a qemu point of
> view.  Obviously we think that the genuine Xen hypervisor is much
> better :-) but it is right for people to have a choice, and having
> qemu emulate more environments is generally good.
>
> But if this functionality is to go into qemu upstream perhaps it
> should be distinguished from `real Xen' functions, because otherwise
> users are going to become very very confused.
>
> Ian.
>
>
>