> >No, I got the impression that Fabrice was taking about virtualization the > > way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the > > works) do it. > > The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's > a couple of fast emulation techniques that are possible. Other than a > hand coded dynamic translator, I reckon qemu + kqemu is about as good as > it can get (unless I'm missing something here). Do you have
Well, VMware does manage direct execution of some kernel code, I believe. VMware's real super-cunningness is doing this as much as they can, instead of emulating all the stuff. That said, I think with suitable optimisations emulating all the kernel code could be acceptable. The unfortunate thing is that the guest can still tell it's in a VMware machine (I'm not clear how) so it's not really *full* virtualisation, it's just about epsilon away from it :-) VT / SVM will solve this properly. > There are a couple of interesting paravirtualization techniques too. > There's the Xen approach (really fast, but very invasive), the L4ka > afterburning (theoritically close to as fast, but less invasive), and > then of course the extremes like UML. The original L4 port of Linux was pretty hard-core stuff. I understand later L4 developments made native ports easier. The afterburner stuff seems to be the next generation of coolness! The afterburning is really neat stuff :-) You can use one kernel for native, L4 guest and Xen guest. The kernel actually does some of the virtualisation work itself by doing (tasteful levels of) self-rewriting / device emulation on its own. You can run normal device drivers, etc. This has to be assisted by some compiler tool-chain stuff that allows the runtime "wedge" to do its job. They have a (crazy but cool) idea that they'll one day be able to live-migrate (i.e. without more than a few hundred ms downtime) virtual machines between L4 hypervisors and Xen hypervisors. Cheers, Mark > >>FWIW, Xen is already using QEMU in this way. It would be very neat to > >>see this technique applied to a Type II VMM. > > > >Do you have any details on this? > > Mark did a really good job of summarizing the current architecture. > > Regards, > > Anthony Liguori > > >>Regards, > >> > >>Anthony Liguori > >> > >> > >>_______________________________________________ > >>Qemu-devel mailing list > >>Qemu-devel@nongnu.org > >>http://lists.nongnu.org/mailman/listinfo/qemu-devel > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel