Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 14/06/2013 06:38, Paul Durrant ha scritto:
>>>> I think the right solution for this is to move towards using
>>>> the normal "-M pc" machine.  libxl can simply use "-M pc
>>>> -machine accel=xen -device xen-platform-pv"; older versions
>>>> that use the xenfv machine will still work.
>>>> 
>>>> And if you do this, you will also get the benefit of
>>>> versioned machine types.
>>>> 
>> 
>> Thanks. I'll have a look at that.
>
> It's a little more complicated than I thought. There are two machine
> types, xenpv and xenfv (i.e. HVM), and they share the accel=xen
> option.

Yes, I was talking of xenfv only.

> Thus QEMU attaches to the VM in the machine code rather than
> the accelerator init code. Using -M pc is therefore not an option,
> unless we perhaps have separate accel options.

You're talking about xen_hvm_init, right?  IIRC there is a hypercall
that lets you know if a domain is PV or FV so you could move large parts
of it to accelerator init.  What's left can be done in "if
(xen_enabled())" (especially those parts that have matching TCG/KVM code
in normal "-M pc" initialization, and have that code currently disabled
for Xen: unifying the two or at least doing an if/else would be nicer).

> Either way this
> doesn't address the backwards compatibility issue. I think QEMU is
> going to need to know which version of the Xen toolstack invoked it
> unless we specify a compatibility matrix.

Yes, "xenfv" needs to stay as legacy for compatibility purposes.  But if
you move the toolchain and QEMU towards using "-M pc" (requiring new
QEMU for new toolchains that do) it would be a very nice cleanup.  It is
also needed if you ever want to support Q35/PCIe.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel