Re: [Xen-devel] [PATCH] libxl: change default QEMU machine to pc-i440fx-1.6

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-06-11 at 11:35 +0100, Stefano Stabellini wrote:
> On Tue, 10 Jun 2014, Ian Campbell wrote:
> > On Fri, 2014-05-23 at 17:07 +0100, Stefano Stabellini wrote:
> I think that the dependency on QEMU >= 1.6 is OK. The Xen PV Device went
> in v1.6.0 and we certainy cannot go back to versions older than v1.5 due
> to missing mapcache fixes. Fabio reported multiple times that QEMU 1.6
> is the first stable version he tested.

OK, then please can we update the README (and any other relevant docs)
as part of this change.

> > > Use pc-i440fx-1.6 regardless of the xen_platform_pci option. Add the
> > > xen-platform device if requested. Choose slot 2 for the xen-platform
> > > device for compatibility with current installations. In case of Intel
> > > graphic passthrough, slot 2 might be needed by the grafic card. However
> > 
> > "graphics"
> > 
> > > now that we can specify the slot explicitly, it is easy to change the
> > > position of the xen-platform device on the PCI bus if graphic
> > > passthrough is enabled.
> > > 
> > > Move the machine options earlier, before any other emulated devices
> > > options. Otherwise the selected PCI slot for the xen-platform device is
> > > not available in QEMU.
> > > 
> > > Specify PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off, because
> > > differently from xenfv, the other QEMU machines do not have that option
> > > off by default.
> > > 
> > > This patch does not change the emulated environment in the guest.
> > > 
> > > Refer to this thread: http://marc.info/?l=xen-devel&m=140023775929625&w=2
> > 
> > This takes me to "[Xen-devel] [v2][PATCH 4/8] xen, gfx passthrough:
> > reserve 00:02.0 for INTEL IGD" which I can't see the link to (including
> > via the 2 replies). Wrong link perhaps?
> > 
> > A Message-Id is generally a better identifier since I can feed it to the
> > archive of my choice and they aren't subject to e.g. future accidentally
> > renumberings etc.
> 
> 1400237624-8505-5-git-send-email-tiejun.chen@xxxxxxxxx

(pedantic: the <>s are formally part of the message ID...)

OK, so I'm still not sure why this message is relevant to the sentence
which precedes the link.


> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > > 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 8abed7b..fef684f 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -476,6 +476,29 @@ static char ** 
> > > libxl__build_device_model_args_new(libxl__gc *gc,
> > >          flexarray_vappend(dm_args, "-k", keymap, NULL);
> > >      }
> > >  
> > > +    flexarray_append(dm_args, "-machine");
> > > +    switch (b_info->type) {
> > > +    case LIBXL_DOMAIN_TYPE_PV:
> > > +        flexarray_append(dm_args, "xenpv");
> > > +        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
> > > +            flexarray_append(dm_args, b_info->extra_pv[i]);
> > > +        break;
> > > +    case LIBXL_DOMAIN_TYPE_HVM:
> > > +        flexarray_append(dm_args, "pc-i440fx-1.6,accel=xen");
> > > +        flexarray_append(dm_args, "-global");
> > > +        flexarray_append(dm_args, 
> > > "PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off");
> > 
> > FWIW you can use flexarray_append_pair which more naturally gathers an
> > option and its argument together (improving readability).
> > 
> > (personally I think the -machine should be pulled into both cases using
> > this method, but that's not a prereq for accepting the patch IMHO)
> > 
> > Other than that the patch itself seems sound (although I dislike code
> > motion mixed with real changes, I suppose this one is small enough that
> > I can cope).
>  
> Should I go ahead with these minor changes

Please.

>  and leave the soundhw problem
> unsolved? I am not keen on fixing that.
> 
> 1401803223.1582.5.camel@xxxxxxxxxxxxxxxxxxxxxx

I came into this at the point where we were discussing how to support
using -device for soundhw, but I missed the bit where it was explained
why it was necessary to switch to that scheme.

If this change leads to regressions where existing cfg files no longer
work then we need to decide if that would be blocker for 4.5. I can't
see why it wouldn't be, but it's up to you and Konrad to agree I
suppose.

Ian.


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