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

[Blue Swirl <blauwirbel@xxxxxxxxx>]

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

> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel