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

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

> -----Original Message-----
> From: Ian Campbell
> Sent: 19 June 2013 09:56
> To: Paolo Bonzini
> Cc: Andreas FÃrber; Stefano Stabellini; Paul Durrant; xen-
> devel@xxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx
> 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.

Xen-devel mailing list



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