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

[Alexander Graf <agraf@suse.de>]

On 02.11.2010, at 09:55, Stefano Stabellini wrote:

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

This is getting confusing :). There are multiple ways of spawning a Xen PV instance I'm aware of:

1) Xen PV context
2) Xen PV context in SVM/VMX container, maintained by Xen
3) Xenner on TCG/KVM
4) Xenner on Xen HVM

For 1 and 2 the way to go is definitely to reuse the xen infrastructure. For 3 I'm very reluctant in requiring dependencies. One of qemu's strong points is that it does not have too many dependencies on other code. If there are strong points for it however, I gladly change my position :).

For 4 however, I haven't fully made up my mind on if it's useful to people (if you say it is, I'm more than glad to get this rolling!) and what the best way to implement it would be.

So I suppose your suggestion is to use the xen infrastructure for case 4? That might work out. Fortunately, all the detection on which backend we use happens at runtime. Since in that case Xen does own the guest's memory, we might even be safe on using its memory mapping functionality. Maybe.

I'm looking very much forward to talking to you about this in Boston. Are you around already?


Alex