[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen |
Date: |
Fri, 13 Aug 2010 17:46:27 +0000 |
On Fri, Aug 13, 2010 at 1:10 PM, Stefano Stabellini
<address@hidden> wrote:
> On Thu, 12 Aug 2010, Blue Swirl wrote:
>> On Thu, Aug 12, 2010 at 2:09 PM, <address@hidden> wrote:
>> > From: Anthony PERARD <address@hidden>
>> >
>> > 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.
- [Qemu-devel] Re: [PATCH 15/15] xen: Add a Xen specific ACPI Implementation to target-xen, (continued)
[Qemu-devel] [PATCH 13/15] vl.c: Introduce getter for shutdown_requested and reset_requested., stefano . stabellini, 2010/08/12
[Qemu-devel] [PATCH 03/15] xen: Add a new target to qemu: target-xen, stefano . stabellini, 2010/08/12
[Qemu-devel] Re: [PATCH 03/15] xen: Add a new target to qemu: target-xen, Anthony Liguori, 2010/08/13
[Qemu-devel] [PATCH 10/15] xen: Introduce the Xen mapcache, stefano . stabellini, 2010/08/12
[Qemu-devel] Re: [PATCH 00/15] RFC xen device model support, Anthony Liguori, 2010/08/13