Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Tue, 2 Nov 2010, Paolo Bonzini wrote:
> The question is, how much do the Xen userspace and Xenner have in common?
> 
> If you remove code that Xen runs in the hypervisor or in the dom0 
> kernel, or code that (like xenconsoled) is IMHO best moved to the Xenner 
> kernel, what remains is the domain builder and of course xenstore 
> handling.  The domain builder is in libxc, which makes it hard to share, 
> and this leaves xenstore.
> 

There is a xen console backend in qemu already (xen_console.c).


> Now, half of it (the ring buffer protocol) already has a million 
> duplicate implementation in userspace, in the kernel, in Windows PV 
> drivers (at least three independent versions), and is pretty much set in 
> stone.
> 
> So, what remains is actually parsing the xenstore messages and handling 
> the tree data structure.  Which is actually a _very_ small part of 
> xenstored: xenstored has to work across multiple domains and clients, be 
> careful about inter-domain security, and so on.  Xenner has the _big_ 
> advantage of having total independence between domUs (it's like if each 
> domU had its own little dom0, its own little xenstore and so on).  While 
> it doesn't mean there are no security concerns with guest-facing code, 
> it simplifies the code to the point where effectively it makes no sense 
> to share anything but the APIs.
> 

All right, if you feel that it would be easier for you to use your own
simplified version, I am OK with that.
However it is important that the mini-libxc, the mini-xenstored and the
qemu domain builder are disable when using xen as accelerator.
As I said before, running pure PV guests in a xen HVM domain should be one of
the targets of the series, and in that case we do want to use the full
featured xenstored and libxc and the libxenlight domain buider.