Xen and Paravirtualization: Virtual Machines Before Hardware Support Caught Up
Xen made x86 virtualization efficient by modifying guest operating systems to cooperate with a small hypervisor, proving paravirtualization before Intel VT-x and AMD-V made unmodified guests easier to run.
Xen approached x86 virtualization by changing the guest contract
In the early 2000s researchers at the University of Cambridge wanted to let multiple operating systems share one commodity server with strong isolation and predictable performance. Full virtualization on x86 was possible, as VMware had demonstrated, but it required sophisticated techniques to preserve the illusion of conventional hardware for unmodified guests. Xen chose a different tradeoff. Instead of pretending perfectly, it exposed an idealized virtual-machine interface and required guest operating systems to be ported to that interface. The foundational 2003 paper, ‘Xen and the Art of Virtualization,’ described a virtual-machine monitor intended to host commodity operating systems with low overhead, resource isolation and performance suitable for real services.[1] This approach became known as paravirtualization. The guest knew it was virtualized and cooperated with the hypervisor rather than forcing the monitor to infer every privileged intention from legacy hardware behavior.
Changing software avoided some hostile hardware behavior
Paravirtualization traded perfect binary compatibility for a cleaner interface. If the guest kernel could be modified, it could ask the hypervisor directly for privileged operations instead of executing instructions that were difficult to virtualize transparently.
Hypercalls replaced selected privileged operations
A paravirtualized Xen guest runs ordinary application code largely as expected, but the guest kernel uses hypercalls to request operations that require hypervisor authority. These calls are analogous to system calls, except the boundary is between a guest operating system and the hypervisor rather than between an application and its kernel. Xen also exposed virtualized time, interrupts and memory-management rules designed to minimize expensive trapping and emulation. The modern Xen handbook summarizes the original idea succinctly: rather than fool a guest into believing it owns real hardware, let it know it is virtualized and give it a purpose-built interface.[2] This was especially effective before x86 processors offered dedicated guest execution modes, because cooperation could eliminate instruction sequences that caused trouble for transparent virtualization.
The guest kernel became part of the virtualization mechanism
In full virtualization the monitor works around an unaware guest. In Xen’s original paravirtualized model, the ported guest participates in maintaining the abstraction, moving some complexity across the boundary rather than keeping it entirely inside the VMM.
Memory virtualization required explicit cooperation
Memory management was one of the hardest parts of early x86 virtualization because page tables are both performance-critical and security-sensitive. Xen required paravirtualized guests to cooperate when updating page tables so the hypervisor could validate mappings and preserve isolation. This avoided some of the expensive shadow-page-table behavior used by transparent approaches while still ensuring that one domain could not map another domain’s memory arbitrarily. The 2003 paper presents this as part of a broader principle: expose a virtual architecture close enough to x86 for efficient ports but different enough to remove features that virtualize poorly.[1] Paravirtualization therefore was not simply a faster system-call convention. It was a redesigned machine contract in which the operating system and hypervisor divided responsibilities deliberately.
The virtual architecture was similar, not identical, to x86
That distinction let existing operating-system code bases be ported with limited changes while giving Xen the control needed for safe multiplexing. The cost was that closed or unmodified guest kernels could not initially use the same path.
Split drivers moved device access through privileged service domains
Xen also separated many device operations into front-end and back-end drivers. A guest domain used a lightweight front-end interface, while a privileged service domain handled access to physical devices through normal drivers. Shared-memory rings and event mechanisms carried requests efficiently between them. This design reduced the amount of device-specific code that had to live inside the hypervisor itself and allowed Xen to reuse existing operating-system driver ecosystems. It also created a systems architecture that looked less like one monolithic virtual-machine monitor and more like cooperating components with carefully controlled privilege. The structure influenced later virtualization and cloud designs, where management services, I/O backends and guest workloads are deliberately isolated into separate protection domains.
Virtualization became a distributed operating-system problem inside one machine
Once I/O services live in separate domains, performance and reliability depend on communication paths between independently scheduled components. Xen therefore turned a single physical server into a small system of cooperating operating-system instances.
Performance made paravirtualization credible for real servers
The Xen paper evaluated workloads such as web serving and operating-system benchmarks and argued that paravirtualized guests could run with relatively low overhead compared with native execution.[1] This evidence was essential. Virtual machines had often been associated with convenience or isolation at the expense of performance, but server consolidation and hosting demanded credible throughput. Xen’s small hypervisor and cooperative guests showed that strong isolation could coexist with serious workloads on commodity hardware. The project quickly attracted both academic and commercial interest, eventually becoming the basis of XenSource and a major technology in early infrastructure clouds. Its success also demonstrated that Linux and BSD kernels were modifiable enough to serve as active participants in a new virtual architecture.
Hardware virtualization removed the requirement to modify every guest
Intel and AMD were developing processor extensions that changed the tradeoff. Intel announced hardware-assisted virtualization for mass-market systems in 2005, adding execution support intended to make virtualization more robust and efficient.[3] Xen evolved to support hardware virtual machines, allowing unmodified operating systems to run with processor assistance while retaining paravirtualized techniques where they still improved performance. The Xen handbook describes this later mixture: HVM guests use hardware virtualization, while paravirtualized drivers can still accelerate I/O and newer modes combine hardware support with cooperative interfaces.[2] Paravirtualization therefore did not vanish when hardware caught up. It became one option in a hybrid design space rather than the prerequisite for running a guest.
Xen became important infrastructure for the early cloud
The ability to divide one server into isolated domains aligned closely with the emerging idea of infrastructure as a service. Virtual machines could be created, scheduled and destroyed as software objects, allowing providers to sell compute capacity without dedicating one physical server to every customer. Xen became particularly significant in early large-scale cloud deployments, where its open-source availability and Linux integration made it attractive for operators who needed to modify and automate the virtualization stack. The Xen Project continues to describe the 2003 paper as the foundational publication for the architecture.[4] The project therefore sits at the transition between virtualization as a systems-research topic and virtualization as a default data-center building block.
Why Xen belongs in operating-system history
Xen belongs in operating-system history because it showed that changing the contract between operating system and hardware could make virtualization practical before processors supplied a dedicated solution. Paravirtualization asked guest kernels to cooperate through hypercalls, validated memory updates and split device drivers, producing an efficient architecture on early-2000s x86 machines. When Intel VT and related extensions arrived, Xen incorporated them rather than treating hardware assistance as a competing philosophy.[5] That evolution is the larger lesson. System boundaries are negotiable. A hypervisor can emulate legacy hardware, expose a new virtual architecture, depend on processor support or mix all three approaches. Xen’s influence on early cloud infrastructure came from exploring that design space openly and demonstrating that virtual machines could be both a research abstraction and a practical unit of server deployment.
Works Cited
- 01
- 02Xen Project User Handbook — Virtualization Concepts handbook.xenproject.org
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead