cs6465 Advanced OS - Lecture 11 - Xen: Paravirtualization

Overview

Xen made efficient x86 virtualization practical before hardware virtualization support arrived: its 2003 paravirtualization design modified guest kernels to replace problematic privileged operations with explicit hypercalls while leaving user applications unmodified. Anton Burtsev explains Xen’s type-1 hypervisor and Domain-0 architecture, then compares shadow paging, direct paging, and nested page tables, including their performance tradeoffs and Xen’s balloon-driver approach to memory reclamation.

Key takeaways

Xen’s original performance strategy was to modify the guest kernel rather than translate every instruction: applications stayed unmodified while privileged kernel operations became explicit hypercalls.
Xen’s split-driver design keeps physical device drivers in Domain-0 and lets guest front ends communicate with them through shared interfaces, reducing the need to emulate hardware in every guest.
Shadow paging hides host machine frames from the guest but traps page-table writes; direct paging avoids much of that overhead by exposing machine frame numbers and requiring validated hypercalls.
Hardware-assisted nested page tables reduce guest-porting effort, but their additional translation walks can increase TLB-miss costs enough that paravirtualized paging may be faster for some workloads.
Xen’s balloon driver reclaims memory through the guest kernel, allowing the guest’s own memory manager to select pages for release instead of having Xen page arbitrary guest memory.
Xen’s hypervisor mediates low-level resources, while Domain-0 supplies much of the control plane and device functionality; this division made Xen practical for cloud deployments but creates a significant trust boundary.

Chapters

0:00 Why Xen’s 2003 Paravirtualization Mattered

Xen appeared in 2003, before Intel VT-x arrived in 2005 and AMD virtualization support followed in 2006.
The first version of AWS ran on Xen, helping establish the system’s importance to cloud computing.
Paravirtualized device drivers, including VirtIO-style interfaces, remain useful when explicit cooperation can outperform hardware emulation.

5:30 Four Ways to Address x86 Virtualization Limits

Popek and Goldberg’s trap-and-emulate model struggles with x86 instructions that do not trap reliably; Robin and Irvine identified 17 such instructions.
Full emulation can cost roughly 2 to 200 instructions per emulated instruction, while binary translation rewrites sensitive code at runtime.
Binary translation can reach an estimated 80 to 97 percent of native performance, but Xen’s approach instead ports the guest kernel and leaves applications unmodified.
Hardware-assisted virtualization, used by systems such as KVM with QEMU, supports unmodified guests but was unavailable when Xen was first developed.

12:25 What a Xen Guest Kernel Must Change

Paravirtualization moves the guest kernel out of ring zero, using ring one where available or ring three on newer 64-bit x86 systems.
The kernel replaces sensitive operations such as CLI, HLT, loading the interrupt descriptor table, and updating CR3 with explicit hypercalls.
A port must also address exceptions, interrupts, page tables, timekeeping, device drivers, and booting without emulating a full BIOS.
Homework 3 applies these ideas to a smaller x86 kernel, where the architecture-specific changes are more tractable than patching Linux.

18:55 Xen Preserves the Full Guest Operating System

Xen changes a narrow architecture-specific boundary rather than stripping away most of Linux or replacing the full operating system with a unikernel.
User applications remain unmodified in ring three, preserving compatibility with Linux filesystems, networking, and POSIX-style interfaces.
Explicit hypercalls can batch operations such as page-table updates, avoiding the cost of trapping on every individual hardware operation.

22:20 Xen’s Type-1 Hypervisor and Domain-0

Xen boots directly on physical hardware as a type-1 hypervisor with a relatively small core, described as roughly 90,000 lines of code around 2005.
After Xen starts, it launches the privileged Domain-0, typically a Linux system that controls guest creation and provides device backends.
The hypervisor handles physical memory management, scheduling, interrupt dispatch, shared-memory grants, and event notifications between domains.
Xen uses event channels for lightweight notifications rather than providing the feature-rich interprocess communication of a conventional microkernel.

30:10 Domain-0, XenStore, and Split Device Drivers

Domain-0 creates guests through Xen control interfaces, supplying memory and starting kernels directly on the paravirtualized interface rather than through a BIOS.
Guest front-end drivers exchange requests with back-end drivers in Domain-0, which then use physical Linux drivers such as an E1000 network driver.
XenStore provides centralized configuration and device-discovery information, while XenBus connects guest and backend device components.
IOMMU protection can prevent Domain-0 device access from overwriting hypervisor memory, reducing reliance on trusting the entire control domain.

36:40 Guest and Hypervisor Address Spaces on 32-bit and 64-bit x86

On 32-bit x86, a typical Linux guest divided its 4 GB address space into 3 GB for applications and 1 GB for the kernel, with Xen placed at the top.
Segmentation restricted a ring-one guest kernel from reaching Xen’s ring-zero memory while still allowing the guest kernel to access user memory.
On 64-bit x86, segmentation limits were no longer enforced, so both guest kernel and applications ran in ring three.
The 64-bit design used separate page tables for guest execution and hypervisor entry, adding a page-table switch when control entered Xen.

41:00 Hypercall Entry and Xen’s Interrupt Interface

Xen initially used the x86 INT 0x82 instruction for hypercalls, then selected faster entry mechanisms through a hypervisor-provided call page.
The lecture distinguishes 32-bit paravirtualized INT calls, 64-bit SYSCALL entry, and VM calls that exit hardware-virtualized guests.
Xen represented interrupt handlers in a simpler, hardware-independent table instead of requiring guests to manage the full x86 interrupt descriptor table format.
A shared per-CPU page let a guest record disabled interrupts and check for pending events, reducing some exits into the hypervisor.

48:30 Guest Frames, Machine Frames, and the Memory Problem

A guest sees guest virtual addresses translated to guest physical frames, but the hypervisor must ultimately place those pages in machine frames in host memory.
In hardware-assisted virtualization, nested page tables translate guest physical frames to machine frames without requiring the guest kernel to manage host locations.
In Xen paravirtualization, guest frame numbers may correspond directly to machine frame numbers, making the guest and hypervisor coordinate page-table updates.
The core safety requirement is to prevent a guest from mapping hypervisor-owned machine memory.

56:45 Shadow Paging: Hypervisor-Maintained Page Tables

With shadow paging, the guest maintains its own page tables, but the hardware CR3 register points to shadow tables populated by Xen.
Xen write-protects guest page tables and traps guest updates, translating guest frame numbers into machine frame numbers in the shadow tables.
Shadow paging can track dirty pages for live migration, but frequent traps and page faults make ongoing synchronization expensive.
Xen can cache shadow tables across CR3 changes, although it must still track whether guest pages are being reused as page tables or ordinary memory.

59:15 Direct Paging and Nested Page-Table Tradeoffs

Direct paging lets the hardware use guest page tables containing machine frame numbers, but Xen validates updates requested through hypercalls.
Guests can batch many page-table changes into a single hypercall, trading kernel-porting effort for fewer traps than shadow paging.
Nested page tables allow unmodified guests but can make TLB misses more expensive because hardware must walk both guest and nested translation structures.
Paravirtualized direct paging can therefore be faster for workloads with heavy TLB pressure, even on machines that support hardware virtualization.

1:03:50 Shadow-Page Faults and Dirty-Page Tracking

When a shadow entry is absent, Xen walks the guest page table, translates a guest frame such as frame 120 to its machine frame, and fills the shadow entry.
Xen can initially map a writable guest page as read-only, then detect the first guest write and mark the page dirty.
A fault caused by a missing guest mapping is delivered to the guest, while faults used internally to build or update shadow mappings are handled by Xen.
During live migration, tracking writes lets Xen identify which pages must be copied again to the destination machine.

1:09:30 Pinned Direct Page Tables and Batched Fork Updates

In direct paging, guest page-table pages become pinned: the guest can read them, but changes must pass Xen’s validation hypercalls.
For fork, a paravirtualized Linux guest can prepopulate a child’s page tables while they are still ordinary writable pages, then submit the tree for validation.
After Xen validates the page-table tree from root to leaves, it protects the pages and permits the hardware to use them through CR3.
Xen switches to shadow-style tracking during migration so it can detect dirty pages and manage changes to machine frame numbers.

1:15:35 Balloon Drivers Reclaim Guest Memory

Xen generally avoids paging guest memory itself and instead uses a balloon driver running inside the guest kernel.
If a guest’s allocation must fall from 1,024 MB to 512 MB, the balloon driver asks the guest kernel to allocate pages and returns them to Xen.
Because the guest kernel understands its page cache and memory pressure, it can choose which pages to reclaim more intelligently than an external hypervisor.
Xen can later increase a guest’s allocation by having the balloon driver release previously reclaimed pages back to the guest.

1:18:55 Event Channels and the Lecture’s Next Topic

Xen event channels provide lightweight notifications between domains, complementing shared-memory communication used by device drivers.
Burtsev ends after covering ballooning and postpones a fuller explanation of event handling to the next lecture.

Transcript excerpt

0:37 Any questions about the homework just to start? All good? Uh okay, so today we're going to talk about Zen. Uh it's a the pioneering virtualization solution which essentially made uh virtual power virtualization possible. So, the main topic of the lecture is related to the pre-virtualization. But, uh in the context of Zen. And Zen is Zen is nice because uh uh it essentially to some degree it's what made the modern cloud possible. So, the first version of AWS was running on Zen. Uh not only binary translation or uh emulation and hardware supported for

1:25 virtualization was what was not available back then, right? So, like if you if you follow the dates, there's so this paper Zen uh shows up in 2003. Uh They already had like a a couple of research uh prototypes, right? And hardware support for virtualization shows up in 2005. I think it Intel VTX. Uh And then AMD followed next year. And the first version didn't have nested page tables. Oh, and today like the reason the we're talking about it, right? So, well, first of all, we're trying to cover the entire spectrum of virtualization solutions. But really there is always this kind of like trade-off. We'll see it later in the

2:14 lecture that uh sometimes to make things faster you can invest a little bit of time and paravirtualize, right? And so you typically paravirtualize device drivers and uh well, again, what's VirtIO? Um VirtIO is good enough, but it's still some kind of a flavor of paravirtualization, right? But also like with uh nested page tables, sometimes actually running without them makes it a little bit faster for you, right? Okay, so cool. So, uh what's going on, right? So we kind of like again from the very beginning of

This is the start of the transcript. Save this video free for the whole transcript, searchable and time-coded.

In this course

Related notes

Summary, takeaways, and chapters were generated by AI from the video's transcript and may contain errors. The video belongs to its creator, Anton Burtsev.