From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnUOx-0000K3-KN for qemu-devel@nongnu.org; Fri, 14 Jun 2013 09:50:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnUOw-0001QS-BO for qemu-devel@nongnu.org; Fri, 14 Jun 2013 09:50:51 -0400 Received: from mail-qc0-x22d.google.com ([2607:f8b0:400d:c01::22d]:38934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnUOv-0001QO-UC for qemu-devel@nongnu.org; Fri, 14 Jun 2013 09:50:50 -0400 Received: by mail-qc0-f173.google.com with SMTP id l10so300408qcy.18 for ; Fri, 14 Jun 2013 06:50:49 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51BB1FB4.1030006@redhat.com> Date: Fri, 14 Jun 2013 09:50:44 -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> In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0039637@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 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