Paul Durrant
2013-Jun-19 09:11 UTC
Re: [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@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel