[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform devic
From: |
Paul Durrant |
Subject: |
Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization |
Date: |
Wed, 19 Jun 2013 09:11:28 +0000 |
> -----Original Message-----
> From: Ian Campbell
> Sent: 19 June 2013 09:56
> To: Paolo Bonzini
> Cc: Andreas Färber; Stefano Stabellini; Paul Durrant; xen-
> address@hidden; address@hidden
> 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
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, (continued)
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paolo Bonzini, 2013/06/14
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paul Durrant, 2013/06/14
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/18
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paolo Bonzini, 2013/06/18
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/18
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Andreas Färber, 2013/06/18
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Ian Campbell, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paul Durrant, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paolo Bonzini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Ian Campbell, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization,
Paul Durrant <=
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paolo Bonzini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paul Durrant, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Ian Campbell, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Ian Campbell, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paul Durrant, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Stefano Stabellini, 2013/06/19
- Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization, Paul Durrant, 2013/06/20