[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



2014-06-11 12:44 GMT+02:00 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.

I tested upstream qemu from 1.2 and based on my test at least qemu 1.6.1 is needed to be fairly complete and stable on xen (no major or critical bugs), I started using it in production for a few month, in the next few days I will start to put also qemu 2.0 on a production system.
I want to be remembered to specify >=1.6.1 because 1.6.0 have critical bug that that prevents all hvm domUs start.
Â

> > > 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.

I think add new option with audio device select and check similar to vga would be good but I'm afraid I do not have time to do it recently.
May still be other cases in addition to the audio to cause problems if you put xen-platform's pci slot fixed, I have not tested further.
Complete the conversion to -device does not seem blocker, FWIK would be blocking the disks part conversion with q35 cipset but is not currently supported by xen.

Sorry for my bad english.
Â

Ian.


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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.