Hypervisors

The classic recipe is “trap and emulate”: run the guest’s kernel with reduced privileges, let every privileged instruction fault, and emulate it in the monitor. Popek and Goldberg showed in 1974 that this works on any CPU where every instruction that can reveal or change the machine’s state is also privileged. The original x86 broke that rule: some sensitive instructions silently behaved differently instead of trapping. VMware worked around it in 1999 by rewriting guest kernel code on the fly (binary translation), and Xen in 2003 by modifying the guest kernel to call the hypervisor directly (paravirtualization).

Intel VT-x and AMD-V fixed the hardware. They add a guest mode with all the usual privilege levels, plus a control structure where the hypervisor says which events should force an exit. On an exit the CPU saves the guest’s state, loads the hypervisor’s, and reports why it stopped, e.g. an I/O port access with its port number, width and direction. The hypervisor handles it and re-enters the guest. AMD’s SVM (AMD-V) and Intel’s VT-x work the same way. Exits are expensive: on a Pentium 4, VMware measured 2,030 cycles to trap and emulate one rdtsc instruction, against 216 cycles for its translated version. First-generation VT-x and AMD-V also left memory virtualization to software (“shadow” page tables), which is why second-level address translation followed: EPT and NPT let the CPU walk the guest’s page tables and the hypervisor’s guest-physical to host-physical map in hardware.

On Linux the loop is visible in KVM’s API. A user-space program opens /dev/kvm, creates a VM and its vCPUs, maps guest memory from its own address space, and calls KVM_RUN. The kernel enters guest mode and handles many exits itself, such as external interrupts and page faults. When the guest touches an I/O port or a memory-mapped device KVM can’t satisfy, KVM_RUN returns with KVM_EXIT_IO or KVM_EXIT_MMIO, and the user-space VMM emulates the device before calling KVM_RUN again. On 64-bit Arm the hypervisor runs at exception level EL2, and Linux asks to be booted there to use the virtualization extensions.

Robert Goldberg’s 1973 Harvard thesis split monitors into two kinds. In Type I, “the VMM runs on a bare machine”. In Type II, “the VMM runs on an extended host, under the host operating system”. ESXi and Xen are the textbook type 1 examples: ESXi installs on the physical server as the platform for VMs, and Xen calls itself a type-1 or bare-metal hypervisor. VirtualBox’s manual calls it a hosted, type 2 hypervisor that needs an existing OS.

Real systems mix the two. Xen boots first, but a privileged first guest, Domain0, runs the management software. Hyper-V sits directly on the hardware, yet it needs a root partition running Windows, which owns the physical devices and serves the other partitions’ device requests over VMBus. KVM turns the Linux kernel itself into the hypervisor: each VM is an ordinary process and each vCPU a thread, so top and kill work on them. Apple’s Hypervisor framework does the same on macOS, from a sandboxed user-space app.

That is why people now separate the hypervisor (the privileged part that runs guests on the CPU and isolates memory) from the VMM (the user-space process that sets up the VM and emulates its devices). On Linux, KVM is the hypervisor and QEMU, Firecracker or Cloud Hypervisor is the VMM. QEMU can also run with no hypervisor at all, emulating the whole CPU in software with TCG, as in the snippet above. Cloud Hypervisor runs on either KVM or the Microsoft Hypervisor (MSHV).

Because a VM’s whole state is memory plus device state held by the hypervisor, it can be moved or saved. Live migration (Clark et al., 2005) copies all memory to the new host while the guest runs, then repeatedly re-sends only the pages dirtied since the last round, and finally pauses the guest to send the remainder and CPU state; the source keeps a consistent copy until the target confirms. A snapshot serializes the same state to files: Firecracker writes a guest memory file and a microVM state file covering KVM and emulated device state, and leaves disks to the user. Restoring a snapshot in a new process resumes the guest where it was, without booting.

Overcommit means the memory configured for all VMs exceeds the machine’s real memory. VMware ESX Server’s 2002 paper introduced two techniques for it. A balloon driver inside the guest allocates and pins pages on the hypervisor’s request, so the guest’s own memory manager decides what to give up. Content-based page sharing merges identical pages across VMs; in one experiment with identical Linux VMs, sharing reclaimed nearly 60% of all VM memory. Linux has the same idea as KSM (Kernel Samepage Merging), originally written for KVM: a daemon scans registered memory and replaces identical pages with one write-protected copy.

Nested virtualization runs a hypervisor inside a VM. Google describes it as levels: the physical host and its hypervisor are L0, the VMs on it L1, and VMs inside an L1 hypervisor L2. Each cloud limits it: Compute Engine supports only KVM at L1, and EC2 offers it on C8i, M8i and R8i instances. Every extra level adds address translations, which KVM has to fold into hardware that supports at most two.

The hypervisor is the wall between tenants, and its biggest attack surface is the device models. In 2015 the VENOM bug (CVE-2015-3456) let a guest user write out of bounds in QEMU’s emulated floppy disk controller, used by Xen and KVM, and possibly run code on the host. That is why newer VMMs emulate very few devices, why Firecracker and Cloud Hypervisor are written in Rust, a memory-safe language, and why AWS’s Nitro Hypervisor leaves out general-purpose operating system components and moves networking and storage to separate Nitro cards.

CPU side channels cross the wall without a bug in the hypervisor. With L1 Terminal Fault (L1TF), a malicious guest on one hyperthread could read data that the sibling hyperthread (the host, or another guest) had brought into the shared L1 cache. The mitigations are costly: flushing the L1 cache on VM entry (the Linux docs report slowdowns from 1% to 50% depending on the workload), pinning each guest to whole cores so tenants never share siblings, or turning SMT off.