| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen on top of xen
> > 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
|
|
|
| |
|
Home