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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo
> Bonzini
> Sent: 14 June 2013 14:51
> To: Paul Durrant
> Cc: Ian Campbell; Stefano Stabellini; qemu-devel@xxxxxxxxxx; xen-
> devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> initialization
> 
> 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.
> 

I think we're still going to need -M xenpv, I think; it's quite distinct from 
pc. I guess we could use -M pc for HVM and gate the accel code as you suggest 
but, if that's the way we're going, it would seem more logical just to ditch 
the accel code for xenpv completely (assuming we can do all we need from the 
machine init) and then use -M pc -accel=xen for HVM guests going forward. But 
that does rather screw up my autodiscovery plans because I would not know, for 
a given qemu binary, which machine type to use. If I create a new xenfv-2.0 
machine type though I *can* do auto discovery... in which case do we need the 
-accel=xen option at all?

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