CPU virtualization techniques
penberg.blogspot.com
penberg.blogspot.com
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. ]
[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...]