| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
Ian Jackson wrote:
Anthony Liguori writes ("Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into
qemu"):
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.
...
No, it's definitely for use with Xen (hypervisor). But it's different
architecturally from how Xen uses QEMU in xen-unstable.
Xenner is an emulator for allowing Xen domUs to be booted without the
Xen hypervisor.
Or "shim". It's almost architecturally identical to the XenSource
developed "shim" for Hyper-V. It seems like a popular thing to do these
days :-)
Xennite is an experimental replacement for the Xen userland management
stack in dom0: it moves more functionality from the Xen tools in dom0
into the qemu-dm process. This is moving in almost the opposite
direction to Xen upstream is moving: we are moving qemu-dm into its
own tiny domain, so that the qemu code doesn't need to run as a
process in dom0; this has important security and scalability
advantages.
Are there separate requirements for stub domains verses Xennite?
Gerd's code is different than what's upstream in QEMU but the question
is whether it's reconcilable with what's upstream. If not, what makes
it that way?
Regards,
Anthony Liguori
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home