Xen devel - Jun 2013 - [PATCH] Remove hardcoded xen-platform device initialization

The xen-platform device should be initialized by the Xen toolstack by
passing the appropriate -device argument on the command line.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 hw/i386/pc_piix.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index d618570..e25012d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -174,9 +174,6 @@ static void pc_init1(MemoryRegion *system_memory,
     pc_register_ferr_irq(gsi[13]);
 
     pc_vga_init(isa_bus, pci_enabled ? pci_bus : NULL);
-    if (xen_enabled()) {
-        pci_create_simple(pci_bus, -1, "xen-platform");
-    }
 
     /* init basic PC hardware */
     pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy,
xen_enabled());
-- 
1.7.10.4

Il 13/06/2013 13:44, Ian Campbell ha scritto:
> On Thu, 2013-06-13 at 18:33 +0100, Stefano Stabellini wrote:
>> On Thu, 13 Jun 2013, Paul Durrant wrote:
>>> The xen-platform device should be initialized by the Xen toolstack
by
>>> passing the appropriate -device argument on the command line.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>
>> This patch is problematic because we can''t know for sure the
version of
>> upstream QEMU that is going to be used with Xen.
>> If we apply this patch and QEMU 1.5 is going to be used with Xen 4.2,
>> guests won''t be able to use PV drivers.
> 
> Is the right answer a lever to disable, rather than enable, it?
> 
> A workaround for the situation you envisage is to use the
> device_model_args config option, not ideal though.
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.

Paolo

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: 13 June 2013 19:03
> To: Ian Campbell
> Cc: Stefano Stabellini; Paul Durrant; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> initialization
> 
> Il 13/06/2013 13:44, Ian Campbell ha scritto:
> > On Thu, 2013-06-13 at 18:33 +0100, Stefano Stabellini wrote:
> >> On Thu, 13 Jun 2013, Paul Durrant wrote:
> >>> The xen-platform device should be initialized by the Xen
toolstack by
> >>> passing the appropriate -device argument on the command line.
> >>>
> >>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >>
> >> This patch is problematic because we can''t know for sure
the version of
> >> upstream QEMU that is going to be used with Xen.
> >> If we apply this patch and QEMU 1.5 is going to be used with Xen
4.2,
> >> guests won''t be able to use PV drivers.
> >
> > Is the right answer a lever to disable, rather than enable, it?
> >
> > A workaround for the situation you envisage is to use the
> > device_model_args config option, not ideal though.
> 
> 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.

  Paul

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

Il 14/06/2013 04:50, Paul Durrant ha scritto:
>> > This patch is problematic because we can''t know for sure
the version of
>> > upstream QEMU that is going to be used with Xen.
>> > If we apply this patch and QEMU 1.5 is going to be used with Xen
4.2,
>> > guests won''t be able to use PV drivers.
>> > 
> Is there not a compatibility matrix? The hardcoded init. is just blatantly
the wrong thing to be doing and it needs to go.
> 
> Could my accompanying toolstack patch not be backported to the next 4.2
release as mitigation?
I think Ian is right.  You should revert the toolstack patch and not
apply this one for now.  Then aim at using "-M pc" in 4.4 (and require
1.6 or 1.7), so that there is no need for a compatibility matrix.

Paolo

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: 14 June 2013 14:53
> To: Paul Durrant
> Cc: Stefano Stabellini; qemu-devel@nongnu.org; xen-devel@lists.xen.org
> Subject: Re: [PATCH] Remove hardcoded xen-platform device initialization
> 
> Il 14/06/2013 04:50, Paul Durrant ha scritto:
> >> > This patch is problematic because we can''t know for
sure the version of
> >> > upstream QEMU that is going to be used with Xen.
> >> > If we apply this patch and QEMU 1.5 is going to be used with
Xen 4.2,
> >> > guests won''t be able to use PV drivers.
> >> >
> > Is there not a compatibility matrix? The hardcoded init. is just
blatantly the
> wrong thing to be doing and it needs to go.
> >
> > Could my accompanying toolstack patch not be backported to the next
4.2
> release as mitigation?
> 
> I think Ian is right.  You should revert the toolstack patch and not
> apply this one for now.  Then aim at using "-M pc" in 4.4 (and
require
> 1.6 or 1.7), so that there is no need for a compatibility matrix.
> 
As I said in another mail on the thread, I don''t think we''ll
ever be able to use -M pc, so I''m planning to create a xenfv-2.0
machine type and leave xenfv with the hardcoded device creation semantic. Then
I''ll add code to libxl to parse qemu''s response to -M help and
choose xenfv-2.0 if it exists (and specify the -device argument accordingly).

  Paul

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: 14 June 2013 14:51
> To: Paul Durrant
> Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org
> 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

Il 14/06/2013 10:11, Paul Durrant ha scritto:
> I think we''re still going to need -M xenpv, I think; it''s
quite
> distinct from pc.
Of course!  Even more: "-M xenpv" should be reused on ARM.
> 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.
There is common code between pv and fv, and that one definitely belongs
in xen_init.  Most fv-only code probably should be in pc_init.  The rest
should move to xen_init though, because it would apply just as well for
example to Q35.  It''s a bit ugly to have fv-only code there, but
it''s
better than having a Xen-specific machine type.  Xen/KVM/TCG should be
as similar as possible at the QEMU level, any difference should be
handled in the toolstack.
> But that does
> rather screw up my autodiscovery plans because I would not know, for
> a given qemu binary, which machine type to use.
There''s no need for that.  4.4 can just use "-M pc"
unconditionally,
<=4.3 will just use "-M xenfv" unconditionally.
> 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?
Yes.  Please try not do things differently from other accelerators.

Paolo

> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: 14 June 2013 15:58
> To: Paul Durrant
> Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> initialization
> 
> Il 14/06/2013 10:11, Paul Durrant ha scritto:
> > I think we''re still going to need -M xenpv, I think;
it''s quite
> > distinct from pc.
> 
> Of course!  Even more: "-M xenpv" should be reused on ARM.
> 
> > 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.
> 
> There is common code between pv and fv, and that one definitely belongs
> in xen_init.  Most fv-only code probably should be in pc_init.  The rest
> should move to xen_init though, because it would apply just as well for
> example to Q35.  It''s a bit ugly to have fv-only code there, but
it''s
> better than having a Xen-specific machine type.  Xen/KVM/TCG should be
> as similar as possible at the QEMU level, any difference should be
> handled in the toolstack.
> 
> > But that does
> > rather screw up my autodiscovery plans because I would not know, for
> > a given qemu binary, which machine type to use.
> 
> There''s no need for that.  4.4 can just use "-M pc"
unconditionally,
> <=4.3 will just use "-M xenfv" unconditionally.
> 
> > 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?
> 
> Yes.  Please try not do things differently from other accelerators.
> 
Ok. I guess we can have the ability to override the machine type in the VM
config, so you could still kick off an older qemu with a newer libxl - but it
sounds like the auto-discovery idea is a no-go then.

  Paul

On Fri, 14 Jun 2013, Paul Durrant wrote:
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of
Paolo
> > Bonzini
> > Sent: 14 June 2013 15:58
> > To: Paul Durrant
> > Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org; xen-
> > devel@lists.xen.org
> > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> > initialization
> > 
> > Il 14/06/2013 10:11, Paul Durrant ha scritto:
> > > I think we''re still going to need -M xenpv, I think;
it''s quite
> > > distinct from pc.
> > 
> > Of course!  Even more: "-M xenpv" should be reused on ARM.
> > 
> > > 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.
> > 
> > There is common code between pv and fv, and that one definitely
belongs
> > in xen_init.  Most fv-only code probably should be in pc_init.  The
rest
> > should move to xen_init though, because it would apply just as well
for
> > example to Q35.  It''s a bit ugly to have fv-only code there,
but it''s
> > better than having a Xen-specific machine type.  Xen/KVM/TCG should be
> > as similar as possible at the QEMU level, any difference should be
> > handled in the toolstack.
> > 
> > > But that does
> > > rather screw up my autodiscovery plans because I would not know,
for
> > > a given qemu binary, which machine type to use.
> > 
> > There''s no need for that.  4.4 can just use "-M pc"
unconditionally,
> > <=4.3 will just use "-M xenfv" unconditionally.
> > 
> > > 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?
> > 
> > Yes.  Please try not do things differently from other accelerators.
> > 
> 
> Ok. I guess we can have the ability to override the machine type in the VM
config, so you could still kick off an older qemu with a newer libxl - but it
sounds like the auto-discovery idea is a no-go then.
xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to just
use -M pc for HVM guests and retain -M xenpv for pv guests.

However it seems to me that we also need a way in libxl to find out
whether QEMU is new enough for us to be able to use -M pc.
We can''t just assume that users will be able to figure out the magic
rune they need to write in the VM config file to solve their VM crash at
boot problem.

We could spawn an instance of QEMU just to figure out the QEMU version
but we certainly cannot do that every time we start a new VM.
Once we figure out the QEMU version the first time we could write it to
xenstore so that the next time we don''t have to go through the same
process again.

Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
>> > 
>> > Ok. I guess we can have the ability to override the machine type
in the VM config, so you could still kick off an older qemu with a newer libxl -
but it sounds like the auto-discovery idea is a no-go then.
> xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to just
> use -M pc for HVM guests and retain -M xenpv for pv guests.
> 
> However it seems to me that we also need a way in libxl to find out
> whether QEMU is new enough for us to be able to use -M pc.
> We can''t just assume that users will be able to figure out the
magic
> rune they need to write in the VM config file to solve their VM crash at
> boot problem.
> 
> We could spawn an instance of QEMU just to figure out the QEMU version
> but we certainly cannot do that every time we start a new VM.
> Once we figure out the QEMU version the first time we could write it to
> xenstore so that the next time we don''t have to go through the
same
> process again.
Can you just assume that 4.4 requires QEMU 1.6 or newer?

Paolo

On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> >> > 
> >> > Ok. I guess we can have the ability to override the machine
type in the VM config, so you could still kick off an older qemu with a newer
libxl - but it sounds like the auto-discovery idea is a no-go then.
> > xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to
just
> > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > 
> > However it seems to me that we also need a way in libxl to find out
> > whether QEMU is new enough for us to be able to use -M pc.
> > We can''t just assume that users will be able to figure out
the magic
> > rune they need to write in the VM config file to solve their VM crash
at
> > boot problem.
> > 
> > We could spawn an instance of QEMU just to figure out the QEMU version
> > but we certainly cannot do that every time we start a new VM.
> > Once we figure out the QEMU version the first time we could write it
to
> > xenstore so that the next time we don''t have to go through
the same
> > process again.
> 
> Can you just assume that 4.4 requires QEMU 1.6 or newer?
I would rather not make that assumption because we cannot control what
distro are going to package. I wouldn''t want a distro to ship with Xen
HVM guests broken because they choose the wrong QEMU version. Of course
we could put that in the release notes, but there are lots of distros
out there and I am pretty sure that at least one of them is not going to
read them.

On Tue, 2013-06-18 at 19:56 +0100, Stefano Stabellini
wrote:
> On Fri, 14 Jun 2013, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of
Paolo
> > > Bonzini
> > > Sent: 14 June 2013 15:58
> > > To: Paul Durrant
> > > Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org; xen-
> > > devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform
device
> > > initialization
> > > 
> > > Il 14/06/2013 10:11, Paul Durrant ha scritto:
> > > > I think we''re still going to need -M xenpv, I
think; it''s quite
> > > > distinct from pc.
> > > 
> > > Of course!  Even more: "-M xenpv" should be reused on
ARM.
> > > 
> > > > 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.
> > > 
> > > There is common code between pv and fv, and that one definitely
belongs
> > > in xen_init.  Most fv-only code probably should be in pc_init. 
The rest
> > > should move to xen_init though, because it would apply just as
well for
> > > example to Q35.  It''s a bit ugly to have fv-only code
there, but it''s
> > > better than having a Xen-specific machine type.  Xen/KVM/TCG
should be
> > > as similar as possible at the QEMU level, any difference should
be
> > > handled in the toolstack.
> > > 
> > > > But that does
> > > > rather screw up my autodiscovery plans because I would not
know, for
> > > > a given qemu binary, which machine type to use.
> > > 
> > > There''s no need for that.  4.4 can just use "-M
pc" unconditionally,
> > > <=4.3 will just use "-M xenfv" unconditionally.
> > > 
> > > > 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?
> > > 
> > > Yes.  Please try not do things differently from other
accelerators.
> > > 
> > 
> > Ok. I guess we can have the ability to override the machine type in
the VM config, so you could still kick off an older qemu with a newer libxl -
but it sounds like the auto-discovery idea is a no-go then.
> 
> xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to just
> use -M pc for HVM guests and retain -M xenpv for pv guests.
> 
> However it seems to me that we also need a way in libxl to find out
> whether QEMU is new enough for us to be able to use -M pc.
> We can''t just assume that users will be able to figure out the
magic
> rune they need to write in the VM config file to solve their VM crash at
> boot problem.
What crash at boot problem?
> We could spawn an instance of QEMU just to figure out the QEMU version
> but we certainly cannot do that every time we start a new VM.
> Once we figure out the QEMU version the first time we could write it to
> xenstore so that the next time we don''t have to go through the
same
> process again.
Due to the device_model_override we might need to make this per-path.
You''d also likely need to store mtime or something in case qemu gets
upgraded, although perhaps that is getting unnecessarily picky...

Ian.

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: 18 June 2013 20:35
> To: Paolo Bonzini
> Cc: Stefano Stabellini; Paul Durrant; qemu-devel@nongnu.org; xen-
> devel@lists.xen.org; Ian Campbell
> Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> initialization
> 
> On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> > Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> > >> >
> > >> > Ok. I guess we can have the ability to override the
machine type in the
> VM config, so you could still kick off an older qemu with a newer libxl -
but it
> sounds like the auto-discovery idea is a no-go then.
> > > xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible
to just
> > > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > >
> > > However it seems to me that we also need a way in libxl to find
out
> > > whether QEMU is new enough for us to be able to use -M pc.
> > > We can''t just assume that users will be able to figure
out the magic
> > > rune they need to write in the VM config file to solve their VM
crash at
> > > boot problem.
> > >
> > > We could spawn an instance of QEMU just to figure out the QEMU
> version
> > > but we certainly cannot do that every time we start a new VM.
> > > Once we figure out the QEMU version the first time we could write
it to
> > > xenstore so that the next time we don''t have to go
through the same
> > > process again.
> >
> > Can you just assume that 4.4 requires QEMU 1.6 or newer?
> 
> I would rather not make that assumption because we cannot control what
> distro are going to package. I wouldn''t want a distro to ship with
Xen
> HVM guests broken because they choose the wrong QEMU version. Of
> course
> we could put that in the release notes, but there are lots of distros
> out there and I am pretty sure that at least one of them is not going to
> read them.
Can''t we just leave the default set at xenfv (as it is in my patch)
until we''re happy that most distros are carrying a new enough qemu?

  Paul

On Wed, 19 Jun 2013, Ian Campbell wrote:
> On Tue, 2013-06-18 at 19:56 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Jun 2013, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On
Behalf Of Paolo
> > > > Bonzini
> > > > Sent: 14 June 2013 15:58
> > > > To: Paul Durrant
> > > > Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org;
xen-
> > > > devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded
xen-platform device
> > > > initialization
> > > > 
> > > > Il 14/06/2013 10:11, Paul Durrant ha scritto:
> > > > > I think we''re still going to need -M xenpv, I
think; it''s quite
> > > > > distinct from pc.
> > > > 
> > > > Of course!  Even more: "-M xenpv" should be reused
on ARM.
> > > > 
> > > > > 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.
> > > > 
> > > > There is common code between pv and fv, and that one
definitely belongs
> > > > in xen_init.  Most fv-only code probably should be in
pc_init.  The rest
> > > > should move to xen_init though, because it would apply just
as well for
> > > > example to Q35.  It''s a bit ugly to have fv-only
code there, but it''s
> > > > better than having a Xen-specific machine type.  Xen/KVM/TCG
should be
> > > > as similar as possible at the QEMU level, any difference
should be
> > > > handled in the toolstack.
> > > > 
> > > > > But that does
> > > > > rather screw up my autodiscovery plans because I would
not know, for
> > > > > a given qemu binary, which machine type to use.
> > > > 
> > > > There''s no need for that.  4.4 can just use
"-M pc" unconditionally,
> > > > <=4.3 will just use "-M xenfv" unconditionally.
> > > > 
> > > > > 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?
> > > > 
> > > > Yes.  Please try not do things differently from other
accelerators.
> > > > 
> > > 
> > > Ok. I guess we can have the ability to override the machine type
in the VM config, so you could still kick off an older qemu with a newer libxl -
but it sounds like the auto-discovery idea is a no-go then.
> > 
> > xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to
just
> > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > 
> > However it seems to me that we also need a way in libxl to find out
> > whether QEMU is new enough for us to be able to use -M pc.
> > We can''t just assume that users will be able to figure out
the magic
> > rune they need to write in the VM config file to solve their VM crash
at
> > boot problem.
> 
> What crash at boot problem?
If you start QEMU as device model on Xen with the wrong machine option
(for example -M pc on an old QEMU), QEMU would probably just abort
during initialization.

> > We could spawn an instance of QEMU just to figure out the QEMU version
> > but we certainly cannot do that every time we start a new VM.
> > Once we figure out the QEMU version the first time we could write it
to
> > xenstore so that the next time we don''t have to go through
the same
> > process again.
> 
> Due to the device_model_override we might need to make this per-path.
> You''d also likely need to store mtime or something in case qemu
gets
> upgraded, although perhaps that is getting unnecessarily picky...
 
I think of device_model_override as an option for developers. People
that use device_model_override can also override the QEMUMachine
version.
I am more worried about your average user that gets a default broken
configuration on her favourite distro.

On Wed, 19 Jun 2013, Paul Durrant wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: 18 June 2013 20:35
> > To: Paolo Bonzini
> > Cc: Stefano Stabellini; Paul Durrant; qemu-devel@nongnu.org; xen-
> > devel@lists.xen.org; Ian Campbell
> > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> > initialization
> > 
> > On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> > > Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> > > >> >
> > > >> > Ok. I guess we can have the ability to override the
machine type in the
> > VM config, so you could still kick off an older qemu with a newer
libxl - but it
> > sounds like the auto-discovery idea is a no-go then.
> > > > xenfv-2.0 is a bad idea, like Paolo wrote, it should be
possible to just
> > > > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > > >
> > > > However it seems to me that we also need a way in libxl to
find out
> > > > whether QEMU is new enough for us to be able to use -M pc.
> > > > We can''t just assume that users will be able to
figure out the magic
> > > > rune they need to write in the VM config file to solve their
VM crash at
> > > > boot problem.
> > > >
> > > > We could spawn an instance of QEMU just to figure out the
QEMU
> > version
> > > > but we certainly cannot do that every time we start a new
VM.
> > > > Once we figure out the QEMU version the first time we could
write it to
> > > > xenstore so that the next time we don''t have to go
through the same
> > > > process again.
> > >
> > > Can you just assume that 4.4 requires QEMU 1.6 or newer?
> > 
> > I would rather not make that assumption because we cannot control what
> > distro are going to package. I wouldn''t want a distro to ship
with Xen
> > HVM guests broken because they choose the wrong QEMU version. Of
> > course
> > we could put that in the release notes, but there are lots of distros
> > out there and I am pretty sure that at least one of them is not going
to
> > read them.
> 
> Can''t we just leave the default set at xenfv (as it is in my
patch) until we''re happy that most distros are carrying a new enough
qemu?
As Ian pointed out, we already start a QEMU instance at host boot time
to serve qdisk requests. We might as well use it to retrieve the QEMU
version and select the machine version based on that.

On Wed, 2013-06-19 at 14:55 +0100, Stefano Stabellini
wrote:
> On Wed, 19 Jun 2013, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini
[mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: 18 June 2013 20:35
> > > To: Paolo Bonzini
> > > Cc: Stefano Stabellini; Paul Durrant; qemu-devel@nongnu.org; xen-
> > > devel@lists.xen.org; Ian Campbell
> > > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform
device
> > > initialization
> > > 
> > > On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> > > > Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> > > > >> >
> > > > >> > Ok. I guess we can have the ability to
override the machine type in the
> > > VM config, so you could still kick off an older qemu with a newer
libxl - but it
> > > sounds like the auto-discovery idea is a no-go then.
> > > > > xenfv-2.0 is a bad idea, like Paolo wrote, it should be
possible to just
> > > > > use -M pc for HVM guests and retain -M xenpv for pv
guests.
> > > > >
> > > > > However it seems to me that we also need a way in libxl
to find out
> > > > > whether QEMU is new enough for us to be able to use -M
pc.
> > > > > We can''t just assume that users will be able
to figure out the magic
> > > > > rune they need to write in the VM config file to solve
their VM crash at
> > > > > boot problem.
> > > > >
> > > > > We could spawn an instance of QEMU just to figure out
the QEMU
> > > version
> > > > > but we certainly cannot do that every time we start a
new VM.
> > > > > Once we figure out the QEMU version the first time we
could write it to
> > > > > xenstore so that the next time we don''t have
to go through the same
> > > > > process again.
> > > >
> > > > Can you just assume that 4.4 requires QEMU 1.6 or newer?
> > > 
> > > I would rather not make that assumption because we cannot control
what
> > > distro are going to package. I wouldn''t want a distro to
ship with Xen
> > > HVM guests broken because they choose the wrong QEMU version. Of
> > > course
> > > we could put that in the release notes, but there are lots of
distros
> > > out there and I am pretty sure that at least one of them is not
going to
> > > read them.
> > 
> > Can''t we just leave the default set at xenfv (as it is in my
patch) until we''re happy that most distros are carrying a new enough
qemu?
> 
> As Ian pointed out, we already start a QEMU instance at host boot time
> to serve qdisk requests. We might as well use it to retrieve the QEMU
> version and select the machine version based on that.
Don''t forget the case where the user has explicitly requested a
different qemu version to what dom0 is using... In that case we have to
start the one they wanted. Should be a minority situation though.

Ian.