| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
Ian Jackson wrote:
Gerd Hoffmann writes ("[Qemu-devel] [PATCH 0/7] merge some xen bits into qemu"):
Here are a bunch of patches which start adding xen support to qemu.
Overview (individual patches have longer descriptions):
Just to clarify: as far as I can tell from the description,
this code has scant relationship with Xen upstream.
I'm generally in favour of pushing functionality out of the Xen branch
of qemu into upstream. But going by Gerd Hoffman's description I
don't think that's what his branch is. His code doesn't appear to be
related to the Xen branch of qemu that we are using.
I think it's more closely related to Xenite and Xenner. Gerd: are you
planning on folding in domain creation? Right now it appears to be a
helper launched after the domain creation.
For example,
With the first four patches in place upstream qemu can replace xen's
qemu-dm for paravirtual domains. The block and nic backend drivers are
full userspace implementations using the grant table device (gntdev).
we only use qemu-dm in paravirtualised domains for certain marginal
functions - in many cases it is not used at all. Certainly the
functionality Gerd describes, such as xen backend block and network
drivers, are not in our qemu tree and we do not intend for them to be
there.
There's no reason they couldn't be though. It's just like blktap.
In a Xen installation this functionality is in the dom0 (host) kernel.
As far as I can see much of Gerd Hoffman's intended submission is
effectively an _emulator_ for Xen guests. That is, it emulates a Xen
host without being one, so that a Xen domU can be run without the Xen
hypervisor. Am I right, Gerd ?
No, it's definitely for use with Xen (hypervisor). But it's different
architecturally from how Xen uses QEMU in xen-unstable.
Personally, I really like the way Gerd has the code structured. It
seems like it could be used as almost a drop-in replacement for qemu-dm
for PV guests. HVM guests would require more work. Of course, the
net/disk support can be completely optionally.
With that said, it would be silly to have two Xen implementations within
QEMU so there has to be some general agreement in the Xen community
about how QEMU is going to be used before merging would make sense.
That probably requires some discussion about how the HVM support would
fit into this architecture.
Regards,
Anthony Liguori
I don't think there's anything wrong with that from a qemu point of
view. Obviously we think that the genuine Xen hypervisor is much
better :-) but it is right for people to have a choice, and having
qemu emulate more environments is generally good.
But if this functionality is to go into qemu upstream perhaps it
should be distinguished from `real Xen' functions, because otherwise
users are going to become very very confused.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home