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

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>