This area is a complex subject and maybe one for a tutorial. The basic x86-IA32 instruction set has 17 opcodes which are not properly virtualised, simply because the designers forgot that when they first laid out the architecture for their 20MHz 386s with 1Mb RAM that with Moore's Law in a decade or so you'd have Joe Blow user running a 4x3GHz 786 with 4Gb RAM wanting to run virtual machines. There are two approaches to achieving true virtualisation within the
Popek and Goldberg criteria:
- The first is to treat the binary code as a mailable entity and modify it on the fly to remove nasty inconveniences. VMware and VBox adopt slightly different strategies here: VMware uses JiT binary translation and VBox uses code scanning and patching but in reality they work and perform "much of a muchness". "User code" pretty much runs flat out, but any Ring 0 code which touches the H/W ends up being interpreted at a 10x or worse slowdown. The blend can be typically between 70-95% of throughput depending on the application mix.
- The second is that first AMD then Intel decided to add an extra layer in the microcode to provide proper virtualisation support (the so called VT-x option), and this is included in the latest x64 chipsets.
The first of these is a mature and tuned technology. It is also extremely complex to do, the second is less mature and a lot simpler for the VM writers to implement. So today as Technologov says they perform about equally but with each iteration of silicon, H/W virtualisation is rapidly overhauling S/W (The overhead in the latest core 2 designs in about one third of what it was in the first version in terms of clock cycles for trapping and despatching a "naughty" instruction.)
What these two approaches do is to allow you to run on OS unchanged against a specific virtualised machine, and as long as you can live with the constraints of that virtualised H/W and the run time implications, then this gives you the easiest and most robust install. It can also give you terrible perceived performance on near-realtime devices such as the mouse and audio. So what both VMware and VBox do is to add para-virtualisation techniques by adding installable VM-aware device drivers which are written to avoid the virtual H/W but instead call the host VMM directly though some guest-to-host connector.
It's in this area that the real performance differences come out, that is if you have VBox Guest Additions (or VMware tools) installed on your client. VMware has good network and block (HDD) drivers which bypass the VMM overhead. VBox uses native I/O virtualisation for both these.
VBox has more efficient mouse and graphics drivers than VMware, at least for basic windowing work. However, the virtual Graphics Adapter that VMware emulates is functionally richer and has better 2D pass-through, so woks better on video apps etc. Neither have any working 3D capability, though the VMware driver does implement very limited 3D functionality.
