From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnVS1-0004mC-RV for qemu-devel@nongnu.org; Fri, 14 Jun 2013 10:58:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnVRx-0008Ad-JS for qemu-devel@nongnu.org; Fri, 14 Jun 2013 10:58:05 -0400 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:64775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnVRx-0008AN-FN for qemu-devel@nongnu.org; Fri, 14 Jun 2013 10:58:01 -0400 Received: by mail-qc0-f178.google.com with SMTP id c11so341646qcv.23 for ; Fri, 14 Jun 2013 07:58:00 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51BB2F73.70902@redhat.com> Date: Fri, 14 Jun 2013 10:57:55 -0400 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> In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0039B3F@LONPEX01CL01.citrite.net> Content-Type: text/plain; charset=UTF-8 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: Paul Durrant Cc: "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Ian Campbell , Stefano Stabellini 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. Paolo