Understanding CPU and I/O Virtualization: How Hypervisors Provide Isolation

1. Overview of Virtualization

Virtualization is conceptually similar to emulation: an operating system can create one or more platforms with the same architecture on a single physical host. Modern OSes include simplified virtualization for CPU and memory, making each process appear as the sole user of the CPU and giving each process its own virtual address space that maps to physical memory.

Hardware devices are also virtualized; for example, processes use Berkeley sockets to access the network without interference, and graphical environments such as GNOME, KDE, or terminal emulators share the screen and input devices, giving the illusion of exclusive use.

Virtualization provides isolation that prevents bugs or malicious actions in one system from affecting others. When the OS itself contains bugs, this isolation can be broken, but a hypervisor can enforce stronger isolation by virtualizing both CPU and I/O.

2. CPU Virtualization

In a native OS, the CPU is time‑shared: a virtual CPU (vCPU) is a time slice on a physical CPU (pCPU). The scheduler saves the current process context and restores another roughly every 10 ms on mainstream systems such as Linux.

vCPU and pCPU differ in execution modes. A vCPU runs in a virtual privileged mode that includes a virtual user mode and a virtual privileged mode, while a pCPU runs in native user and privileged modes. The hypervisor either simulates privileged instructions itself or collaborates with the vCPU to implement them.

When a hypervisor is deployed, it runs in the pCPU’s privileged mode, and guest operating systems run inside virtual machines (VMs) in user mode. The hypervisor must not only multiplex the pCPU but also trap and emulate privileged instructions issued by the guest OS, which is the core challenge of CPU virtualization.

The seminal 1974 paper by Gerald J. Popek and Robert P. Goldberg introduced three instruction classes—privileged, control‑sensitive, and behavior‑sensitive—and stated that full virtualization is possible only if every sensitive instruction is a privileged one. The hypervisor intercepts and handles these instructions to control VM access to hardware, enabling isolation, resource scheduling, memory virtualization, and device emulation.

3. Types of Virtualization

From the guest OS perspective, CPU virtualization can be:

Full native simulation : the hypervisor completely simulates the pCPU, allowing the guest OS to run unmodified and remain unaware of the hypervisor.

Paravirtualization (non‑full simulation) : the guest OS and hypervisor cooperate; the guest can detect the hypervisor’s presence.

4. Virtualization Mechanisms

The choice of virtualization technique depends on the ISA and application requirements.

Virtualizable ISA : If all sensitive instructions are privileged, the ISA can be fully virtualized using a trap‑and‑emulate model. Examples include ARMv8, RISC‑V, MIPS, PowerPC, and SPARC. In this model, a privileged instruction executed by a vCPU causes a trap; the hypervisor captures the trap and precisely emulates the instruction.

Non‑virtualizable ISA : If a sensitive instruction is not privileged, it will not trap in virtual user mode, making trap‑and‑emulate impossible. For example, on 32‑bit x86 without hardware virtualization extensions, the POPF instruction changes interrupt flags in native mode but does nothing in virtual user mode, so the ISA cannot be fully virtualized without additional engineering techniques.

5. I/O Virtualization

When a guest OS boots, it detects hardware and forwards I/O requests to the hypervisor. Two common solutions are:

Integrate device management into the hypervisor as a subsystem. This increases hypervisor code size and complexity, limiting the number of drivers that can be safely included.

Assign all I/O devices to a dedicated VM and forward other VMs’ I/O requests to that VM. This leverages existing guest drivers but requires careful isolation mechanisms, such as shared‑memory channels, to maintain VM separation.

For devices that must be shared among VMs, simple mutexes in the guest driver break isolation; therefore, a dedicated I/O VM that exclusively owns the device and provides services to other VMs is preferred.

6. Why Use Virtualization?

Virtualization offers several advantages:

Multiple OSes can run concurrently on the same hardware (e.g., a real‑time OS like VxWorks alongside a general‑purpose OS such as Linux), combining real‑time capabilities with rich application ecosystems.

Subsystems (drivers, network stacks, file systems) can be isolated in separate VMs, improving security and code reuse; a crash or attack in one VM does not affect others.

Linux, as a mainstream GPOS, is free and supported by a large open‑source community; hypervisors can enforce license isolation for derived code.

Loose coupling between software and hardware allows guest OSes to be ported with minimal changes, extending the maintenance life of long‑lived systems.

Hypervisors reduce the overall code base compared to full operating systems, lowering the number of potential vulnerabilities and the associated risk.

Physical hardware consolidation saves space, power, and cost; VM snapshots and migration simplify backup and disaster recovery.