From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up1KS-0005Yk-RL for qemu-devel@nongnu.org; Tue, 18 Jun 2013 15:12:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Up1KR-00039N-TQ for qemu-devel@nongnu.org; Tue, 18 Jun 2013 15:12:32 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:54142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up1KR-00039E-N0 for qemu-devel@nongnu.org; Tue, 18 Jun 2013 15:12:31 -0400 Received: by mail-wi0-f175.google.com with SMTP id m6so3805862wiv.8 for ; Tue, 18 Jun 2013 12:12:31 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51C0B119.8070704@redhat.com> Date: Tue, 18 Jun 2013 21:12:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Ian Campbell , Paul Durrant , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" 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? Paolo