Xen: The Magic of Paravirtualization

The "new" virtualization trend (VMware) relies on complex binary translation to handle privileged instructions. Xen took a different path: Paravirtualization (PV). Instead of tricking the guest OS, we modify it to be aware that it's running on a hypervisor.

The Hypercall Interface

In a standard OS, a process makes a syscall to the kernel. In Xen, the guest kernel makes a hypercall to the Xen hypervisor (Domain 0).

/* Simplified hypercall example in guest kernel */
inline int HYPERVISOR_console_io(int cmd, int count, char *str)
{
    int ret;
    unsigned long op = __HYPERVISOR_console_io;
    __asm__ __volatile__ (
        "int $0x82"
        : "=a" (ret)
        : "0" (op), "b" (cmd), "c" (count), "d" (str)
        : "memory"
    );
    return ret;
}

Notice the int $0x82? That's the specific interrupt vector Xen listens for.

Memory Management

In PV mode, the guest OS is responsible for its own page tables, but it must register them with Xen. This avoids the overhead of "shadow page tables" used in full virtualization.

The guest uses a "machine-to-physical" (m2p) mapping table provided by the hypervisor to understand where its "physical" memory actually sits in the real hardware RAM.

Why PV?

Because the guest knows it's virtualized, it can optimize I/O using grant tables and event channels (essentially virtual interrupts). This is why a Xen guest can push 1Gbps of traffic while a fully virtualized guest struggles at 200Mbps. If your OS doesn't have a Xen-aware kernel, you're leaving performance on the table.