Re: xen/xen vs xen/kvm nesting with pv drivers

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

. snip..
> > >> It would be lovely if someone would work on this, but it is a very large
> > >> swamp.
> > >>
> > >> ~Andrew
> > > Does the L1's Dom0 have to issue the hypercalls directly? Would it be
> > > possible to get the L1's Dom0 to issue the request to the L1 hypervisor
> > > and that to call the L0 hypervisor? This would seem to fit the current
> > > architecture fairly closely. (Sorry if I've got the terminology wrong)
> > 
> > In principle, L1 Xen could proxy hypercalls from L1 dom0 to L0 Xen.
> > 
> > However, event channels and grant maps affect the full L1 guest physical
> > space, and need to be managed by the L1 Xen, not the L1 dom0.  At that
> > point, you are talking about proxying the event/grant interface, but as
> > Xen tries to specifically stay out of the way of disk/network in dom0,
> > it isn't obvious where the split lives.
> > 
> > >
> > > Regarding multiple XenStores, I appreciate there would be significant
> > > problems, but you'd only have a maximum of two XenStores, one for the
> > > xenback drivers (the current XenStore) and one for the xenfront drivers
> > > (that talks to the parent hypervisor).
> > 
> > Until this point, event channels, grant maps and xenstore have been
> > global per-domain with no concept of separate namespaces.  As a result,
> > changing the existing code to work in a nested way will be very invasive.
> > 
> > 
> > Fundamentally, the problem is that Xen's virtual architecture does not
> > nest cleanly.  This is easy to identify in hindsight, but about 15 years
> > too late to act upon.  I don't have any good suggestions, short of
> > something radical like using virtio.
> 
> There was an paper along with an RFC implemention of PV drivers in
> nested dom0. CCing a co-worker who may remember it better than me.
> 

http://code.google.com/p/xen-blanket/
http://xcloud.cs.cornell.edu/pubs/xen_blanket.pdf

Are the links.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel