> thanks to everyone who replied! What I was thinking of was something along
> the lines of Daniel's suggestion below, i.e. if the VMX architecture makes
> it possible to setup enough proper traps etc. so that you can actually
> "cheaply" emulate all these VMX registers/features and thus have multiple,
> nested HVM's.
I wasn't able to find if it's possible to trap VMX instructions that are
executed in noon-root mode but it's my assumption that Intel did the sensible
thing and made that work :-) They definitely cause a trap in AMD's SVM.
> I don't know if it's useful but it is at least interesting to
> think about how it would work and how big/small a performance cost you
> could get away with if you had, say, 10 nested HVM's with Linux or
> something running in the innermost ;) I guess the emulation cost will be
> bigger for the "non-primary" HVM's (the primary being the one running
> closest to the hardware). But I guess that even stuff like VT-d directed
> I/O could be recursively emulated and yet still have "true" direct I/O for
> the innermost operating system.
Yeah, that sounds plausible. Similarly, with nested pagetables / hardware
assisted paging, you'd save overhead relative to nesting n shadow pagetables.
It'd be interesting whether by emulating these virtualisation-friendly
features it might be possible to do nested full virtualisation without
completely destroying performance... I guess it'd entail a fair bit of scary
coding to make it work but it would be really cool.
It could certainly be useful for testing stuff if nothing else. I already do
development and testing by running PV Linux on Xen, all wrapped up in a Xen
HVM domain on my test box. It works quite well and the performance is usable
for testing / debugging.
I think Qemu can now emulate VMX / SVM instructions when it's run as an
emulator (not as a virtualiser), so anyone who really needs virtual machines
with HVM support right now can get it that way - if they don't mind taking a
massive performance hit.
Cheers,
Mark
> MH > From: stodden@xxxxxxxxxx> To: bguthro@xxxxxxxxxxxxxxx> Date: Thu, 31
> Jan 2008 14:33:46 +0100> Subject: Re: [Xen-devel] Xen inside Xen with VMX?>
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx; paradigm__82@xxxxxxxxxxx> > > On Thu,
> 2008-01-31 at 07:07 -0500, Ben Guthro wrote:> > Current VT implementations
> do not have this ability, AFAIK.> > Indeed. There's only one root mode, and
> the processor has no concept of> recursively stacking roots and
> accompanying protection levels on top of> each other.> > Nonetheless, root
> mode could be emulated, i.e. via shadow VMCBs,> optional shadow NPTs and
> emulation of the respective instruction subset.> > Would suffer from the
> same (most probably solvable) problems regarding> privilege compression and
> the like, but probably an interesting> excercise.> > Maybe one should put
> it on some (nonexisting) list for interesting> [academic] projects.> >
> regards,> daniel> > -- > Daniel Stodden> LRR - Lehrstuhl für Rechnertechnik
> und Rechnerorganisation> Institut für Informatik der TU München D-85748
> Garching> http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx> PGP
> Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B> > > >
> _______________________________________________> Xen-devel mailing list>
> Xen-devel@xxxxxxxxxxxxxxxxxxx> http://lists.xensource.com/xen-devel
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home