|
xen-devel
Re: [Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new target to
On Fri, Aug 13, 2010 at 12:47 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Blue Swirl writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 03/15] xen: Add a new
> target to qemu: 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.
>
> Qemu's targets include much more of Qemu's system emulation than is
> appropriate for Xen, because the hypervisor is doing more of the
> work. For example, there is no representation of the guest CPU state
> outside the hypervisor so Qemu doesn't see that at all.
But you could easily ignore QEMU's CPU state, or even better would be
to support some kind of CPU state synchronization. KVM also manages
the CPU when it is charge, but at the transition points the state is
synched with QEMU state. For example, what should happen to CPU on
system reset on Xen? In this version, reset is completely ignored.
About the other changes, for example cpu_physical_memory_map() seems
to do very different things on Xen than QEMU. But this can be handled
easily by adding some kind of indirection to exec.c or just:
if (xen_enabled()) {
xen_func();
} else {
tcg_func();
}
or add stubs for non-Xen case and then:
xen_func();
if (!xen_enabled()) {
tcg_func();
}
> So it makes sense to do Xen emulation in Qemu as a new target than
> just as a machine.
It's also possible to add a new x86 CPU model like 'xen-x86'.
> Yes, in principle Xen for Sparc, PPC and ARM are possible; some of
> these have existed in the past although targets other than i386,
> itanium and amd64 aren't currently supported by xen-unstable. So
> perhaps the currently-introduced xen target should be called
> target-i386-xen. However, in practice since in a Xen system Qemu
> doesn't deal with CPU instructions these other targets will be much
> more like each other than (say) i386 is close to m68k.
>
> Or to put it all another way: from the point of view of Qemu, Xen is
> a weird kind of cpu architecture whose instruction emulation is done
> "by magic" and Qemu doesn't need to care vary much about that.
I don't see how this is so different from KVM, which is integrated to
QEMU cleanly. Even if the changes would be more invasive that way
(like the memory changes which KVM hasn't done so far), I'd still
think that would be better for everyone than having two versions of
the same code with some changes. They would eventually drift apart.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home