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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 19 June 2013 09:56
> To: Paolo Bonzini
> Cc: Andreas Färber; Stefano Stabellini; Paul Durrant; xen-
> devel@lists.xen.org; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-
> platform device initialization
> 
> On Wed, 2013-06-19 at 10:41 +0200, Paolo Bonzini wrote:
> > Il 19/06/2013 10:29, Ian Campbell ha scritto:
> > >> > You could check for existence of the pc-i440fx-1.6 machine and infer
> > >> > that it is at least v1.6 (might break in some distant future of course
> > >> > and for current git commits until your changes get merged).
> > > Actually, this raises an interesting point. AIUI "pc" is simply and
> > > alias for the most recent "pc-X.Y" and "pc-X.Y" is present to allow for
> > > qemu "upgrading" the set of emulated hardware, as in it represents
> > > changing the set of emulated peripherals, not just fixing bugs in the
> > > emulation etc, is that right?
> >
> > Usually it represents adding _features_ to the emulation.  There are
> > some cases where the set of emulated peripherals change (e.g. pvpanic
> > added in 1.5), but it's the exception rather than the rule.  There are
> > also some cases of bug-compatibility, but again they're not the most
> > common use of versioned machine types.
> >
> > You do not know how older guests react to those new features, and you
> > want to prevent moving guests to older versions that lack some features.
> >  For these reasons, libvirt always sticks to the alias target that was
> > found at creation time.
> 
> I had a grep around libvirt wondering how it handled this and didn't
> find it. The approach you describe makes perfect sense when you have a
> persistent config. The case with xl is more like your example 5:
> 
> > Example 5: you use "virsh create" to start a VM based on an XML file,
> > rather than "virsh define"+"virsh start" as in examples 1-2.  You lose
> > any guarantee that hardware does not change.  Not frowned upon as much
> > as example 4, since the VM is supposed to be transient.
> 
> For something like xapi we'd likely want to support some sort of model
> similar to libvirt, so whatever we do at the libxl layer needs to
> consider both approaches.
> 
> > It would require two QEMU invocations per "xl create".  However, most of
> > the startup time of QEMU is loading dynamic libraries.  A good deal of
> > that time amortizes well over two invocations of QEMU.
> 
> Not to mention that on a system already running a domain or two there is
> a good chance that at least the relevant bits of QEMU are already in
> RAM.
> 
> In fact, I wonder if we could just query the qemu which is running to
> provide dom0 itself with qdisk services, at least in the case where the
> guest is configured to use the same version of qemu.
> 

...in which case can we agree to accept an undocumented override ability in the cfg file. If we're going to introduce some form of auto-selection then we should at least allow developers to bypass it if they need to. I'm happy to get rid the the enumeration, and go for a freeform string which gets passed as the -machine optval if it's specified.

  Paul