Virtualization Concepts¶
Xen supports several virtualization modes. Understanding the differences helps you choose the right mode for your workload and hardware.
The two primary modes are paravirtualization (PV) and hardware virtual machine (HVM). Between them sit several hybrid modes that borrow features from both.
Paravirtualization (PV)¶
In PV mode, the guest operating system is aware that it is running in a virtual machine. Instead of emulating real hardware, Xen provides a streamlined interface (hypercalls) that the guest uses directly. This produces fast, efficient virtualization — but requires a guest OS that has been modified to use the Xen interface.
Modern Linux kernels include full PV support. Windows guests cannot run in pure PV mode.
Hardware Virtual Machine (HVM)¶
In HVM mode, the guest operating system runs as if it were on real hardware. Xen emulates a complete set of virtual devices (network card, disk controller, etc.) using QEMU. The guest requires no modifications and does not need to know it is virtualized.
HVM uses CPU virtualization extensions (Intel VT-x or AMD-V) to handle privileged instructions without software emulation. All modern server processors include these extensions.
The downside of full hardware emulation is overhead: emulating hardware registers and interrupts is slower than the direct hypercall interface PV uses.
Hybrid modes¶
In practice, pure PV and pure HVM are rarely the best choice. Hybrid modes combine elements of both to improve performance.
HVM with PV drivers (PVHVM)¶
An HVM guest using paravirtualized network and disk drivers instead of emulated hardware. The guest boots in HVM mode but uses the faster PV interfaces for I/O. This is often the best choice for Linux guests on hardware where PVH is not yet available.
PVH¶
PVH boots the guest as a PV kernel but uses hardware virtualization extensions for memory management and system calls instead of a software-emulated PV MMU. The result is a fast, lightweight VM with no emulated hardware at all — no QEMU, no BIOS, no legacy boot sequence.
PVH is the recommended mode for Linux guests on modern hardware. It offers the performance of PV with the hardware support of HVM.
Choosing a mode¶
For Linux guests on modern hardware, use PVH if the kernel and toolstack support it. Otherwise use HVM with PV drivers (PVHVM).
For Windows guests or unmodified operating systems, use HVM.
For embedded or specialized use cases, consult the documentation for the relevant Xen sub-project.
Why so many modes?¶
The number of names here can be confusing at first, but they reflect how Xen actually evolved rather than arbitrary branding.
Early x86 hypervisors had to emulate an entire real machine — motherboard, BIOS, disk and network controllers, even the legacy 16-bit boot process — because guest operating systems assumed they were running on real hardware. This is full virtualization, and it’s slow: almost everything the guest does has to be trapped and emulated in software.
Xen’s original idea was the opposite: instead of fooling the guest into thinking it’s on real hardware, let it know it’s virtualized and give it a fast, purpose-built interface instead. That’s paravirtualization — guests call directly into the hypervisor (hypercalls) rather than using emulated hardware, which is what makes PV so lightweight.
Around the same time, Intel and AMD added hardware virtualization extensions (VT-x, AMD-V) that made full virtualization practical without modifying the guest at all — this became HVM. Unlike PV, HVM guests need no changes, at the cost of the overhead full emulation still carries for anything the hardware extensions don’t cover.
From there, PV and HVM started borrowing from each other to close that performance gap: HVM guests picked up paravirtualized disk and network drivers, then paravirtualized interrupts and timers too (PVHVM), while PV gained a mode that uses hardware extensions for memory management and system calls instead of its original software-only approach (PVH). Each step traded away a bit of the “pure” PV or HVM model for whatever combination performed best — which is why the modes read like a spectrum rather than two clean categories.
XenStore¶
XenStore is a small shared database that Xen, dom0, and guests use to exchange configuration and status information — a guest’s name, its memory allocation, device state, and similar small values, not bulk data. Each domain has its own area of the store, and the relevant drivers are notified whenever a value they care about changes; it’s how, for example, a guest’s disk or network device gets attached after the guest has already booted.
Inspect it directly with:
xenstore-ls
This is mainly useful for debugging: if a guest doesn’t seem to be picking up a configuration change, checking XenStore shows whether the value actually arrived.
Security modules (XSM)¶
Xen includes an optional mandatory access control framework called XSM, built on the same FLASK architecture that underlies SELinux. By default dom0 has broad control over the system; an XSM policy lets you restrict that — which domains can talk to each other over event channels or grants, which can use device passthrough, and what a privileged domain is allowed to do.
Most deployments don’t need this — it’s aimed at environments with strict isolation requirements between guests, or between guests and dom0. See the XSM/FLASK reference, maintained in the Xen source tree, for building Xen with XSM enabled and writing a policy.
Other hardening options¶
Beyond XSM, Xen has a few other opt-in features aimed at reducing what an attacker who compromises a guest can reach:
Driver domains move a device driver — most often for networking — out of dom0 into its own isolated domain, so a compromised or buggy driver can’t be used to attack dom0 directly.
pvgrub runs a PV guest’s bootloader inside the guest itself, rather than having dom0 parse and execute code from the guest’s filesystem — a common attack surface for PV boot.
Device model stub domains move QEMU’s device emulation for HVM guests into its own minimal domain instead of running it in dom0 (see the stub domains reference for setup).
None of these are needed for typical use; they matter most in multi-tenant environments where guests don’t trust each other or dom0. See the wiki’s Securing Xen page for the full threat model, driver domain, and pvgrub setup details.