This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen
From: Blue Swirl <blauwirbel@xxxxxxxxx>
Date: Fri, 13 Aug 2010 17:46:27 +0000
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>
Delivery-date: Fri, 13 Aug 2010 10:47:33 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=r6YXm0ux/npJxWz0XRNEcGvEIEVIbmGvxhf9YGDnyEk=; b=NU9iMmylH+sZgM/Pk+smSbUZ9BtJtJnStW+6YxDUnkrtTKDz2g6dOZinDCSx4MChI/ XafAtLu5HoGIIDCpd4BVHvtdHMgZKdctt/xkXIRyPC+Vr8ExPy8QRZIfkpIIHCwXXUJh QCkFb3oB02ZRE/jOqh8uF6reNFfBEC3D5SIMM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=RjBvpbIw9tgNdn2KsXjeV7/Zc4Fxo8nCPBx4kRVL2lBSO60EZUXgeOU8yqz+v3/57i m6QOnjwvz6To87Df/Y1L4P71MPqGLP+Z3/u8NUpnDm+ybYDqqbiXJCVjLjv8JRUCgWOw 3B17hJrGTLej6UmUCqF7gETnc1cEGmkPXzILE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1008130204120.2545@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1008121244200.2545@kaball-desktop> <1281622202-3453-3-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <AANLkTimiij2BGt9eRmeLih+OUbdfy8W_+-zkFsysEoo8@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1008130204120.2545@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Aug 13, 2010 at 1:10 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 12 Aug 2010, Blue Swirl wrote:
>> On Thu, Aug 12, 2010 at 2:09 PM,  <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> >
>> > 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.

What about Itanium? The patch already adds some conditional code.

>> > +/*
>> > + * 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 Makefile.target we have just these lines:
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o

The stub functions return -ENOSYS.

The benefit is that Xen code would then be fully integrated with QEMU.
Xen would benefit from improvements to the shared code, vice versa for

> 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.

I'm not afraid of the impact, from an architectural standpoint the
completely integrated version would be much more preferable.
Self-contained solution is not unlike out-of-tree version, it will
bitrot and die.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>