From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH] Remove hardcoded xen-platform device initialization Date: Wed, 19 Jun 2013 14:55:11 +0100 Message-ID: References: <1371117054-5694-1-git-send-email-paul.durrant@citrix.com> <1371145442.6955.64.camel@zakaz.uk.xensource.com> <51BA0943.7050705@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD00394C5@LONPEX01CL01.citrite.net> <9AAE0902D5BC7E449B7C8E4E778ABCD0039637@LONPEX01CL01.citrite.net> <51BB1FB4.1030006@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0039B3F@LONPEX01CL01.citrite.net> <51BB2F73.70902@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0039C9E@LONPEX01CL01.citrite.net> <51C0B119.8070704@redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD004B477@LONPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD004B477@LONPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: Paolo Bonzini , Ian Campbell , "xen-devel@lists.xen.org" , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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.