Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: groundwork for xen support

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Daniel P. Berrange writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 05/13] xen: 
groundwork for xen support"):
> This particular check is doing two different jobs in one go. I think 
> they need to be dealt with separately.
> 
>  - Check to see if running on Xen or not. This is a similar idea to
>    to pv_ops where we have one kernel binary, and probe at runtime
>    to decide whether to run in KVM, Xen, VMWare or bare metal mode.

I don't think this is correct for the Xen case.  Certainly it is not
correct for a qemu invoked by the Xen management tools, and it is also
not correct for a qemu invoked by hand on a system which already has
xend etc.

If you're trying to run qemu under Xen but standalone without xend
then you're going to have to tell qemu that that's what you want.
Otherwise if you try to run the same qemu under Xen but _with_ xend,
qemu in dom0 will create a domain bypassing xend and cause all sorts
of trouble.

Autodetection of this kind of thing is fragile, and in the Xen
toolstack case also unnecessary (since the Xen toolstack can invoke
qemu with appropriate options to tell it only to do the emulation
parts).

So I think the default mode of operation for qemu instructed to
provide a Xen domU environment should be 100% software, or via KVM if
KVM is available.  KVM is designed as a facility to be used by user
processes without negotiation with the system administrator so it is
fine to autodetect that and use it.

The Xen hypercall and domain management interfaces are not like that:
the interfaces provided by the hypervisor et al should be used only by
cooperation with the Xen management stack.

>    This is important to QEMU too. Merging the source trees for all 
>    projects using QEMU is just the first step. A single binary for
>    all is the holy grail, though may not be practical for Mini-OS
>    usage

I'm certainly in favour of closer integration.  If qemu upstream are
willing to take all of our code, including the parts which serve modes
of operation and features which qemu upstream don't agree are needed,
then excellent.

But I think that for now it would be easier to concentrate on
providing interfaces to allow the qemu-xen tree to mainly be
additional code which goes through well-defined public interfaces to
the rest of qemu.  (From this point of view it's a shame that qemu
itself isn't more like a library than an executable.)

Certainly the minios port can't be the same executable.  The qemu code
is statically linked with minios into what amounts to a monolithic PV
guest kernel.

> If we want QEMU to explicitly created Xen domains from scratch, rather than
> attaching to an existing one, then there needs to be a way to reliably 
> specify this behaviour via the CLI.

Yes.

And this should not be done by default because on a system with xend,
you don't want to be messing with xend's idea of the running domains.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel