From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpLEs-0003Cx-4g for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:28:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpLEp-0003Jv-Sw for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:28:06 -0400 Received: from smtp.citrix.com ([66.165.176.89]:62136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpLEp-0003JV-JP for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:28:03 -0400 Date: Wed, 19 Jun 2013 17:27:50 +0100 From: Stefano Stabellini In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD004BCFF@LONPEX01CL01.citrite.net> 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> <1371629505.22783.53.camel@zakaz.uk.xensource.com> <9AAE0902D5BC7E449B7C8E4E778ABCD004BCFF@LONPEX01CL01.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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: Paul Durrant Cc: "qemu-devel@nongnu.org" , Paolo Bonzini , "xen-devel@lists.xen.org" , Ian Campbell , Stefano Stabellini On Wed, 19 Jun 2013, Paul Durrant wrote: > > -----Original Message----- > > From: qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org > > [mailto:qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org] On > > Behalf Of Stefano Stabellini > > Sent: 19 June 2013 14:53 > > To: Ian Campbell > > Cc: Paolo Bonzini; Paul Durrant; xen-devel@lists.xen.org; qemu- > > devel@nongnu.org; Stefano Stabellini > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Remove hardcoded xen- > > platform device initialization > > > > On Wed, 19 Jun 2013, Ian Campbell wrote: > > > On Tue, 2013-06-18 at 19:56 +0100, Stefano Stabellini wrote: > > > > On Fri, 14 Jun 2013, Paul Durrant wrote: > > > > > > -----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. > > > > > > > > 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. > > > > > > What crash at boot problem? > > > > If you start QEMU as device model on Xen with the wrong machine option > > (for example -M pc on an old QEMU), QEMU would probably just abort > > during initialization. > > > > > > > > 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. > > > > > > Due to the device_model_override we might need to make this per-path. > > > You'd also likely need to store mtime or something in case qemu gets > > > upgraded, although perhaps that is getting unnecessarily picky... > > > > I think of device_model_override as an option for developers. People > > that use device_model_override can also override the QEMUMachine > > version. > > Are you suggesting we allow a freeform -machine option in libxl, or are you suggesting they point device_model_override at a script which drops the -M argument and inserts their new choice before invoking qemu? I am suggesting that we could have a qemu_machine_override option in QEMU, or maybe a device_models_args_override that not only adds any user supplied arguments to QEMU (like the current device_model_args) but also replace the default arguments completely.