How KVM Works: VM Exits, EPT, and Why a Guest Is Scheduled Like a Process

A process that starts a virtual machine does not execute guest instructions the way it executes its own. When the guest is running, the CPU is in a special non-root mode. The host kernel only regains control when the hardware decides an exit is required. That boundary is what makes KVM possible without rewriting every guest instruction.

This article explains that contract: how the Linux kernel becomes a hypervisor, what a VM exit is, how memory translation works with EPT, and why the guest is still scheduled like any other process on the host.

The contract

KVM turns the Linux kernel into a type-2 hypervisor. User space (almost always QEMU) creates a VM, allocates guest memory, and asks the kernel to run a virtual CPU. The kernel uses hardware virtualization extensions (Intel VT-x or AMD-V) so that guest code runs directly on the physical CPU until something forces an exit back to the host.

The guest sees its own kernel, its own page tables, and its own devices. From the host scheduler's point of view, the vCPU is just a thread that spends most of its time inside a long-running ioctl.

The QEMU / KVM split

QEMU runs in user space and owns device models and guest memory backing. KVM is the kernel module that owns virtual CPUs and the translation machinery. The run loop is an ioctl on a vCPU file descriptor that rarely returns; it returns only on a VM exit that needs user-space handling.

Hardware modes and the VMCS

Intel VT-x has VMX root mode (host) and non-root mode (guest). The VMCS stores guest and host state plus exit controls. VMLAUNCH or VMRESUME enters the guest; a VM exit restores host state and jumps to the KVM handler.

What causes a VM exit

Most computation and EPT-hitting memory accesses do not exit. Exits occur for emulated I/O, certain MSRs, CPUID, EPT violations, host interrupts, halt, and hypercalls. Each exit has state-save cost; features like EPT and APICv reduce the rate.

Memory virtualization

Shadow paging (software) maps GVA to HPA and traps page-table writes. EPT/NPT (hardware) lets the CPU walk guest tables (GVA to GPA) and EPT (GPA to HPA) together. Guest page-table updates no longer exit; only EPT misses do. The guest sees GPAs, not real HPAs.

The guest is still a process

Each vCPU is a thread. Inside KVM_RUN it is a kernel-mode runnable task. On return to user space it is an ordinary schedulable thread subject to CFS, cgroups, and NUMA. This is distinct from containers, which share the host kernel. The VM exit is the cost of the separate kernel and page tables.

Misconceptions

KVM alone is not a full hypervisor. Not every instruction exits. The guest does not see real physical addresses. VM exits are not system calls.

Takeaways

KVM uses hardware extensions so guest code runs until a configured event forces an exit. Memory is two-dimensional via EPT or shadow. Each vCPU remains a host-scheduled thread. The exit is the price of isolation.