From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH] Remove hardcoded xen-platform device initialization Date: Fri, 14 Jun 2013 15:10:14 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD0039C9E__18857.6238732368$1371222722$gmane$org@LONPEX01CL01.citrite.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51BB2F73.70902@redhat.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paolo Bonzini Cc: "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo > Bonzini > Sent: 14 June 2013 15:58 > To: Paul Durrant > Cc: Ian Campbell; Stefano Stabellini; qemu-devel@nongnu.org; xen- > devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device > initialization > > Il 14/06/2013 10:11, Paul Durrant ha scritto: > > I think we're still going to need -M xenpv, I think; it's quite > > distinct from pc. > > Of course! Even more: "-M xenpv" should be reused on ARM. > > > I guess we could use -M pc for HVM and gate the > > accel code as you suggest but, if that's the way we're going, it > > would seem more logical just to ditch the accel code for xenpv > > completely (assuming we can do all we need from the machine init) and > > then use -M pc -accel=xen for HVM guests going forward. > > There is common code between pv and fv, and that one definitely belongs > in xen_init. Most fv-only code probably should be in pc_init. The rest > should move to xen_init though, because it would apply just as well for > example to Q35. It's a bit ugly to have fv-only code there, but it's > better than having a Xen-specific machine type. Xen/KVM/TCG should be > as similar as possible at the QEMU level, any difference should be > handled in the toolstack. > > > But that does > > rather screw up my autodiscovery plans because I would not know, for > > a given qemu binary, which machine type to use. > > There's no need for that. 4.4 can just use "-M pc" unconditionally, > <=4.3 will just use "-M xenfv" unconditionally. > > > If I create a new > > xenfv-2.0 machine type though I *can* do auto discovery... in which > > case do we need the -accel=xen option at all? > > Yes. Please try not do things differently from other accelerators. > 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. Paul