Re: [Xen-devel] Xen on top of xen

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > e.g. a scheme whereby the "outermost" Xen trapped SVM
> > instructions issued by
> > the current nested guest and built up a shadow copy of
> > HVM-related data
> > structures, then ran the "inner" HVM guest using these?
> > Future additions to
> > SVM implementations (such as nested paging) would reduce the
> > frequency with
> > which you have to bounce back into the guests.
>
> I'm not sure if it's worth the effort tho'. It would be relatively slow
> (because you'd first get the penalty of the VMExit/VMRun pair, and then
> the additional code to emulate the VMExit/VMRun set.

Mmmm.  The thing that looks to me like it would really make performance nasty 
is jumping in and out of all the levels of nesting in order to do IO 
emulation...

What if IO emulation were being handled by a device model hidden in the 
guest's firmware (has been suggested before for different reasons)?  You'd be 
running the innermost guest context on the host CPU directly, as previously 
suggested, then on an IO exit you could just reflect the IO instruction into 
the device model in that guest.  You potentially wouldn't need to re-enter 
the nested Xen that "owned" the guest until the innermost guest's timeslice 
ran out naturally.

I may well be missing something here, as this ain't my forte ;-)

> > Being able to run HVM Xen in HVM Xen could be useful for
> > testing.  Also, from
> > a management perspective it would make it possible to
> > subdivide the machine
> > between multiple users who each wanted to run a few virtual
> > machines - just
> > give them each a Xen in an HVM domain.  Further levels of
> > nesting would be
> > overkill, and probably give horrible performance.
>
> Of those, the management one is the more applicable to our engineering
> efforts (i.e. the one that will "sell more processors"), but I'm pretty
> sure that the effort is much greater than the gain.

Yep.  Also, the nested management problem could equally be tackled by 
modifying Xen to support some more advanced concept of rights to map memory, 
etc - or even changes at the tools level to make management "look" more 
nested.

Being able to nest Xen is just a /conceptually/ simple way to do this which 
(if it worked) gets us a load of stuff for free (CPU accounting for a domain 
group, atomic suspend/resume for a group, atomic migration for a group, etc.)

> Do you (or anyone else) know if the PPC version supports nested
> virtualization?

I know z/VM supports it (no surprise - z/VM supports all sort of crazy but 
cool things), and it seems like the kind of thing IBM might do - precisely 
for management reasons ;-)  I would guess that the PPC version of Xen doesn't 
support it (yet) but maybe the POWER hypervisor does?  I've cc-ed Hollis 
who'll be able to set the record straight :-)

Cheers,
Mark
-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel