From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= Subject: Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization Date: Tue, 18 Jun 2013 23:38:26 +0200 Message-ID: <51C0D352.7070701__34702.3791786798$1371591625$gmane$org@suse.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: "qemu-devel@nongnu.org" , Paolo Bonzini , Paul Durrant , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.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 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. 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 -- = SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnberg