nice article. after reading that i found that this virtualbox article - http://www.virtualbox.org/wiki/VirtualBox_architecture - made a lot more sense (it goes into implementation details for vb, which isn't addressed in the original article, but which dynamically switches between emulation and virtualisation as necessary)

I only skimmed through the VirtualBox article but it seems to me it's simply explaining how QEMU works (VirtualBox is derived from QEMU).

The "switching dynamically between emulation and virtualization" is simply what I referred to as "hardware emulation" using dynamic binary translation. Of course, when the host and guest CPUs are the same, you end up running bulk of the original native code pretty much as-is. But because you're dynamically generating the code, you end up causing a trap to the hypervisor for the corner cases.

The VirtualBox article is not clear on what it does when hardware supports virtualization (Intel VT-x ("Vanderpool") and AMD-V (SVM) support) but I am guessing it also does what QEMU does, which is to use KVM (or whatever the equivalent is on other platforms than Linux).

What these extensions do is eliminate dynamic binary translation completely. You only trap to the hypervisor on PIO and MMIO accesses and few other minor cases. But all this is controlled by hardware and KVM kernel subsystem and the hypervisor itself doesn't touch the guest instruction stream.

[ Disclaimer: I'm not that familiar with KVM internals so the above explanation is probably a slight over-generalization. ]

vb is, as far as i understand things, similar to qemu + qvm86, if that's any help.

[i've since re-read both and i don't really understand your point. you describe 3 approaches: emulation, [hardware] virtualization, and paravirtualization. qemu (alone) does emulation; qvm86 does virtualization; vb does both (like qemu + qvm86). i get the impression you're correcting some mistake i've made, but i can't see what it is...]