WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Mon, 28 Jul 2008 10:24:42 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx, Gerd Hoffmann <kraxel@xxxxxxxxxx>
Delivery-date: Mon, 28 Jul 2008 08:25:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18573.56967.678947.315212@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <m2n.s.1KNSd3-002QXI@xxxxxxxxxxxxxxxxxxxxxx> <18573.51733.193631.369340@xxxxxxxxxxxxxxxxxxxxxxxx> <488DD8CE.3020508@xxxxxxxxxxxxx> <18573.56967.678947.315212@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080501)
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