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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2013-06-19 at 14:55 +0100, Stefano Stabellini wrote:
> On Wed, 19 Jun 2013, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: 18 June 2013 20:35
> > > To: Paolo Bonzini
> > > Cc: Stefano Stabellini; Paul Durrant; qemu-devel@nongnu.org; xen-
> > > devel@lists.xen.org; Ian Campbell
> > > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device
> > > initialization
> > > 
> > > On Tue, 18 Jun 2013, Paolo Bonzini wrote:
> > > > Il 18/06/2013 20:56, Stefano Stabellini ha scritto:
> > > > >> >
> > > > >> > Ok. I guess we can have the ability to override the machine type in the
> > > VM config, so you could still kick off an older qemu with a newer libxl - but it
> > > sounds like the auto-discovery idea is a no-go then.
> > > > > xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to just
> > > > > use -M pc for HVM guests and retain -M xenpv for pv guests.
> > > > >
> > > > > However it seems to me that we also need a way in libxl to find out
> > > > > whether QEMU is new enough for us to be able to use -M pc.
> > > > > We can't just assume that users will be able to figure out the magic
> > > > > rune they need to write in the VM config file to solve their VM crash at
> > > > > boot problem.
> > > > >
> > > > > We could spawn an instance of QEMU just to figure out the QEMU
> > > version
> > > > > but we certainly cannot do that every time we start a new VM.
> > > > > Once we figure out the QEMU version the first time we could write it to
> > > > > xenstore so that the next time we don't have to go through the same
> > > > > process again.
> > > >
> > > > Can you just assume that 4.4 requires QEMU 1.6 or newer?
> > > 
> > > I would rather not make that assumption because we cannot control what
> > > distro are going to package. I wouldn't want a distro to ship with Xen
> > > HVM guests broken because they choose the wrong QEMU version. Of
> > > course
> > > we could put that in the release notes, but there are lots of distros
> > > out there and I am pretty sure that at least one of them is not going to
> > > read them.
> > 
> > Can't we just leave the default set at xenfv (as it is in my patch) until we're happy that most distros are carrying a new enough qemu?
> 
> As Ian pointed out, we already start a QEMU instance at host boot time
> to serve qdisk requests. We might as well use it to retrieve the QEMU
> version and select the machine version based on that.

Don't forget the case where the user has explicitly requested a
different qemu version to what dom0 is using... In that case we have to
start the one they wanted. Should be a minority situation though.

Ian.