Re: [Xen-devel] Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen support

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> On Tue, Jul 29, 2008 at 08:32:11AM -0500, Anthony Liguori wrote:
>   
>> Why wouldn't the Xen backends be added by appropriate -net or -drive 
>> options?  For instance, qemu -drive file=foo.img,if=xen -net nic,model=xen
>>     
>
> That would work for certain setup tasks, but not all. In Xen's branch
> of QEMU, the machine init function has to set various hypervisor 
> parameters which aren't directly associated with QEMU command line
> args, and initialize things like the map-cache for > 4GB guest support.
>   

map-cache is one of those things I don't expect to ever get merged.

> In the Xennite work I had further stuff going on there too - more general
> initialization of Xenstore parameters - eg stuffing the name & uuid from
> QEMU's argv into right place in xenstore. 
>   

Ideally, I'd like to see Xen/KVM integration look like this:

1) Xen support is detected in configure (libxc et al) and conditionally 
enabled.
2) When running on bare metal, detect whether KVM acceleration is 
available, also detect if kqemu acceleration is available
3) When running under Xen, detect that Xen is available, and create a 
full virt domain
4) If a user specifies a type=xen device, it should Just Work provided 
you are in a Xen environment (erroring appropriately)
5) A user can explicitly specify -M xenpv.  If running under Xen, this 
would create a Xen PV guest.  If running on bare metal, Xenner would be 
used to present a Xen shim layer.  This should work with KVM 
acceleration or without KVM acceleration.  Bonus points if it works with 
kqemu too.

For 1-4, the user experience should not be different at all.  This of 
course doesn't mean that users would be forced to interact directly with 
QEMU or that QEMU cannot be running within a stub domain.  It would be 
good if these things could be automatically detected though.

Regards,

Anthony Liguori

> Daniel
>