Slashdot Mirror
Pointers for Developing x86 Virtualization?
josh asks: "For my next project, I've decided I want to do something related to x86 virtualization (the way VMware does it or Plex86 not Xen/Bochs/etc.) but I really don't know where to start. Googling hasn't been helpful (just look at the results if you don't believe me). Are there any resources for learning about this kind of x86 virtualization? I know virtual 8086 mode wouldn't work, but without that what advantage does something like VMware have over something like Bochs? Are there any F/OSS projects aimed at something along the lines of my thinking? Please enlighten me with any references and resources you might have. Thanks!"
Of course, they also have the option to make something else other than X86 the base architecture upon which they support virtualized X86 (and maybe if we're lucky other cores also). It would make a lot more sense to do this kind of thing on top of something new than to stuff it all in some kind of messy architecture extension as you suggested.
Of course, this still adds to the mess either way, but it does make some sense.
Maybe that's why Transmeta did it.
Fantastic idea, I would suggest you look at the L4Ka and related projects (http://l4ka.org/projects/hazelnut/).
Please do not create a new project from scratch: there are enough.
What is needed though is adapting existing operating systems (e.g. Linux, BSD, etc) to work in these virtualised environments. Further to this, also supporting co-ooperative virtualise environments.
Your efforts in this area would be very well looked upon.
VMWare, in the workstation and GSX version, runs on top of a host OS. ESX is its own "OS". In the IBM world, the VM "OS" layer is very specialized and so far as I know, used for just allocating resources to VM instances... The hardware helps a lot in this case as well.
Idea: What would be the possibility of a "Meta" PC hardware/OS platform? Possibly having zero reselblence to PCs of today, no PC compatable BIOS, N/S bridge concept gone, etc... The hardware, and a thin VM managemnt OS works together to virtualize the hardware, making it appear to be a PC to the VMed OSs.
One of the few companies that has years of experience with dynamic recompiling emulation is ardi (www.ardi.com). Their 68k synthetic cpu was worked on for several years, achieving incredible performance, but alas, only 1/3 cpu speed on average. See http://www.ardi.com/SynPaper/node12.html.
Now of course in theory if you had a lot of cache you could approach native cpu speeds, assuming that you always executed the same code over and over again. Caching certainly is the key to performance here, just like in CPUS. But realistically, you can't always keep every dynamic block in cache. Eventually it will be invalidated and new blocks will have to be translated. Much faster than emulation (orders of magnitude) but still not quite full host cpu speed.
Your point about translating the assembly code is an interesting point, but fails to account for the fact that this has to happen on the fly. Thus the 1/3 bound is not theoretical, but simply a practical one. I'm sure newer techniques will come along to improve this.
Come on, that's still the old circa 1995 results they published back then -- they are quoting results on a 75MHz 486 for Chris' sake! I haven't seen any evidence that the ARDI guys have done much development in the last ten years, and I suspect they are paying their bills with other full-time jobs.
There have been plenty of demonstrations of 75% to 100% of native performance being achieved by dynamic recompilations, by products such as the Digital FX86 and Connectix VirtualPC. The HP Dynamo research project even managed to exceed 100% efficiency by clever optimizations during the recompilation! (Of course they didn't start from uber-optimized code, but then again little real-world code has seen whole-program optimization over library or even module boundaries.)