From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] Remove hardcoded xen-platform device initialization Date: Fri, 14 Jun 2013 09:50:44 -0400 Message-ID: <51BB1FB4.1030006__19718.6555517421$1371217975$gmane$org@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0039637@LONPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Il 14/06/2013 06:38, Paul Durrant ha scritto: >>>> I think the right solution for this is to move towards using >>>> the normal "-M pc" machine. libxl can simply use "-M pc >>>> -machine accel=xen -device xen-platform-pv"; older versions >>>> that use the xenfv machine will still work. >>>> >>>> And if you do this, you will also get the benefit of >>>> versioned machine types. >>>> >> >> Thanks. I'll have a look at that. > > It's a little more complicated than I thought. There are two machine > types, xenpv and xenfv (i.e. HVM), and they share the accel=xen > option. Yes, I was talking of xenfv only. > Thus QEMU attaches to the VM in the machine code rather than > the accelerator init code. Using -M pc is therefore not an option, > unless we perhaps have separate accel options. You're talking about xen_hvm_init, right? IIRC there is a hypercall that lets you know if a domain is PV or FV so you could move large parts of it to accelerator init. What's left can be done in "if (xen_enabled())" (especially those parts that have matching TCG/KVM code in normal "-M pc" initialization, and have that code currently disabled for Xen: unifying the two or at least doing an if/else would be nicer). > Either way this > doesn't address the backwards compatibility issue. I think QEMU is > going to need to know which version of the Xen toolstack invoked it > unless we specify a compatibility matrix. Yes, "xenfv" needs to stay as legacy for compatibility purposes. But if you move the toolchain and QEMU towards using "-M pc" (requiring new QEMU for new toolchains that do) it would be a very nice cleanup. It is also needed if you ever want to support Q35/PCIe. Paolo