Who I Am: The Hypervisor and Its Domains

Quick ref

xl list enumerate running domains

xl create cfg start a domU from config

xl console N attach to guest console

xl info host + hypervisor facts

xl top live per-domain CPU/mem

xl migrate D host live migrate a guest

xenstore-ls dump the config/status tree

Who I Am: The Hypervisor and Its Domains

I am a thin Type-1 layer booted before any OS, owning the physical CPU, the MMU, and the scheduler; everything else runs in a domain.

dom0

Privileged control domain that owns hardware drivers, runs the toolstack, and brokers I/O for guests.

domU

Unprivileged guest domain; the workload tenants I schedule and isolate.

driver domain

Deprivileged domain holding a real device (NIC/disk) so a dom0 driver crash can't take down the host.

stub domain

Per-HVM-guest minimal domain running QEMU device emulation outside dom0 for isolation.

Note dom0 is just a domain with extra privileges — disaggregating drivers and emulators into separate domains shrinks the trusted computing base.

Execution Modes

Mode	CPU/MMU	I/O	Notes
`PV`	Paravirtualized, hypercalls, no VT-x needed	PV split drivers only	Legacy; no nested page tables, vulnerable to some speculative attacks.
`HVM`	Full hardware virt (VT-x/AMD-V) + EPT/NPT	Emulated (QEMU) + optional PV	Runs unmodified OSes; uses stub/qemu for device emulation.
`PVH`	HW virt for CPU/MMU, no emulated platform	PV drivers, virtual interrupts	Modern default — lean boot, smaller attack surface, no QEMU.

Tip Prefer PVH for new Linux/BSD guests: it keeps HVM's hardware isolation while dropping the emulated-platform attack surface.

CPU Scheduling

credit2

Default weight + cap fair-share scheduler with load balancing across pCPUs.

null

Static 1:1 vCPU→pCPU pinning for latency-critical / NFV workloads, no balancing overhead.

xl sched-credit2 -d D -w 512

Set a domain's scheduling weight (relative share).

xl vcpu-pin D vcpu pcpu

Pin a vCPU to physical CPUs to control NUMA locality and cache behavior.

xl cpupool-*

Partition pCPUs into pools, each with its own scheduler instance.

xl vcpu-set D n

Hot-adjust the number of online vCPUs for a guest.

Memory: Translation & Ballooning

Address layers

Guests see pseudo-physical frames; I map those to machine frames. HVM/PVH use hardware EPT/NPT for guest-physical→machine translation; classic PV used direct page-table validation via hypercalls.

Reclaim & share

The balloon driver inflates inside a guest to return frames to me; populate-on-demand backs HVM startup. Page sharing and paging let me oversubscribe carefully.

xl mem-set D 2048

Target a guest's current allocation via the balloon driver.

xl mem-max D 4096

Set the hard ceiling a guest can ever balloon up to.

Warning Ballooning a guest below its working set triggers in-guest swapping or the OOM killer — set maxmem sensibly and never overcommit dom0.

I/O: Split Drivers, Grants & Event Channels

Virtual I/O is a frontend/backend pair: the guest's frontend talks to a backend in dom0 or a driver domain over shared memory and signals.

grant references

Permission tokens letting a backend map or copy a frontend's pages — the controlled cross-domain memory channel.

event channels

Lightweight virtual interrupts/IPIs used to signal ring activity between domains.

vif / xen-netfront

PV network split driver pair (frontend in guest, netback in backend).

vbd / xen-blkfront

PV block device split driver pair (blkfront ↔ blkback).

Rings carry requests/responses; grants move the bulk data; event channels wake the other side. Together they form the data path, not the whole architecture.

XenStore: The Control Plane

A small hierarchical, transactional key-value database that domains use for configuration discovery, device negotiation, and status — not a data path.

xenstore-ls -f

Recursively dump the tree with full paths.

xenstore-read /local/domain/N/name

Read a single node.

xenstore-write path value

Set a node (e.g. trigger frontend/backend state transitions).

xenstore-watch path

Block on changes; how drivers handle hotplug and connect handshakes.

Note Device setup is a XenStore handshake: backend and frontend advance a state field (Initialising→Connected) while exchanging grant/event-channel info.

PCI Passthrough & IOMMU Isolation

xl pci-assignable-add 0000:03:00.0

Detach a device from dom0 and mark it assignable.