On Fri, Aug 13, 2010 at 1:10 PM, Stefano Stabellini
> 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
> 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