From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38042 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oju1z-000553-AM for qemu-devel@nongnu.org; Fri, 13 Aug 2010 09:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oju1u-0006OY-5m for qemu-devel@nongnu.org; Fri, 13 Aug 2010 09:10:39 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:22522 helo=SMTP.EU.CITRIX.COM) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oju1t-0006ON-V2 for qemu-devel@nongnu.org; Fri, 13 Aug 2010 09:10:38 -0400 Date: Fri, 13 Aug 2010 14:10:48 +0100 From: Stefano Stabellini Subject: Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen In-Reply-To: Message-ID: References: <1281622202-3453-3-git-send-email-stefano.stabellini@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Perard , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini On Thu, 12 Aug 2010, Blue Swirl wrote: > On Thu, Aug 12, 2010 at 2:09 PM, wrote: > > From: Anthony PERARD > > > > This patch adds a new Xen device model target to Qemu, called > > target-xen. > > I don't understand why it would be a target, QEMU calls CPU > architectures targets. Isn't it possible to have Xen for Sparc, PPC or > ARM? It should really be just a machine, not copy&paste from x86 > target. > It is not possible to have Xen device models for Sparc, PPC or ARM: the only architecture that supports Xen HVM guests is x86 and x86_64. Also most of the x86 copy and paste are definitions or stubs that haven't really changed in a very long time. > > +/* > > + * This next section was clone-and-hacked from the version in exec.c > > + * :-(. But the exec.c version is full of tcg-specific stuff and > > + * assumptions about phys_ram_base. > > Then fix those assumptions and introduce xen specific hooks, like KVM. > That comment goes back to the very first qemu-xen integration, it is not so relevant anymore. I don't know kvm hooks well enough to be sure that something similar could work well for Xen too and honestly I don't see many benefits in doing so. In particular I am afraid that taking that route might cause a much heavier impact on common code and APIs and ultimately could cause more problems than it solves. As you can see the current approach has the benefit of being self-contained and considering that the xen device model use case works only on x86, doesn't do any cpu emulation and needs a specific set of emulated hardware, I think it makes sense to have its own target.