The Hardware That Makes Virtual Machines Possible

A guest kernel expects to execute privileged instructions — installing page tables, masking interrupts, changing privilege level. Left alone on real hardware it would either fail or, worse, actually succeed and take over the machine. Early virtualization solved this in software: trap-and-emulate where the architecture cooperated, and binary translation rewriting instruction streams where it did not. Both worked and both were slow, particularly for kernel-heavy workloads.

Hardware virtualization support restructured the problem by adding a mode *beneath* the kernel's existing privilege levels (Why Kernel Mode Is Actually Privileged). The guest kernel runs at what it believes is full privilege, but inside a container whose escape hatches the hypervisor configures. Sensitive operations cause a transition to the hypervisor — conventionally called a VM exit — which handles them and resumes the guest. Everything else runs natively at full speed.

The performance model follows directly from that design: guest code that does not exit is native speed; the cost is the exits. This is why a compute-bound loop in a VM performs essentially like bare metal, while an I/O-heavy or interrupt-heavy workload can show noticeable overhead. Reducing exit frequency has been the central optimisation target of virtualization for two decades, which is why paravirtualized drivers and device passthrough exist.

The second half of the problem is memory. The guest kernel builds page tables mapping guest-virtual to what it believes is physical memory. But guest-physical is itself a fiction the hypervisor maintains, so a second mapping is needed from guest-physical to host-physical. Doing that in software meant the hypervisor maintaining shadow page tables and intercepting every guest page-table update — correct, and very expensive.

Second-level address translation puts that mapping in hardware. The MMU walks the guest's tables to get a guest-physical address, then walks the hypervisor's tables to get a host-physical one, without the hypervisor being involved (The MMU: Translation and Protection in One Check, The Page-Table Walk: Dependent Loads All the Way Down). Guest page-table updates become ordinary memory writes rather than trapped operations, which removed a large source of exits.

The cost is that a TLB miss is now more expensive, because a full walk traverses two levels of tables rather than one — a nested walk touching substantially more memory than a native one (When Translation Itself Is the Bottleneck). This is the concrete reason TLB pressure matters more inside a VM than outside, and why huge pages often show a larger benefit in virtualised environments (Huge Pages: More Coverage per Entry, and What It Costs).

Hardware virtualization gives a strong architectural boundary: the guest cannot read host memory or another guest's memory, cannot escape its privilege container without a hypervisor defect, and sees a consistent machine abstraction. That is a genuinely robust isolation primitive and is why VMs remain the boundary of choice for mutually distrusting tenants.

What it does not virtualize is the *microarchitecture*. Guests on the same physical core share caches, predictors, translation buffers, memory bandwidth and the interconnect. Those are not partitioned by the virtualization extensions, so a noisy neighbour affects your performance and, as Side Channels: When Performance Optimisations Leak and Spectre and Meltdown: When Speculation Crossed a Boundary showed, may in some circumstances observe something about your execution.

This is the sharp distinction from containers, which do not use these mechanisms at all: containers are OS-level isolation — separate namespaces and resource limits over a *shared kernel* — so their boundary is the kernel's system-call surface rather than a hardware-enforced one. Neither is universally better; the cloud domain treats the comparison, its performance implications and when to choose which in Containers vs Virtual Machines, and this domain's contribution is only the hardware mechanism underneath the VM side.