From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up3bm-0005UV-QH for qemu-devel@nongnu.org; Tue, 18 Jun 2013 17:38:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Up3bl-0000lM-N4 for qemu-devel@nongnu.org; Tue, 18 Jun 2013 17:38:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33386 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Up3bl-0000lE-Dd for qemu-devel@nongnu.org; Tue, 18 Jun 2013 17:38:33 -0400 Message-ID: <51C0D352.7070701@suse.de> Date: Tue, 18 Jun 2013 23:38:26 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= 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> <51C0B119.8070704@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: "qemu-devel@nongnu.org" , Paolo Bonzini , Paul Durrant , Ian Campbell , "xen-devel@lists.xen.org" Am 18.06.2013 21:35, schrieb Stefano Stabellini: > On Tue, 18 Jun 2013, Paolo Bonzini wrote: >> Il 18/06/2013 20:56, Stefano Stabellini ha scritto: >>> xenfv-2.0 is a bad idea, like Paolo wrote, it should be possible to j= ust >>> 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 versio= n >>> 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? >=20 > 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 t= o > read them. 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). Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg