How devices work

A vCPU with no machine around it is a calculator. Guests boot because something answers MMIO, DMA, and interrupts the way the firmware and the operating system expect. MX's device layer is that machine.

How a guest talks to hardware

Drivers do not call host APIs. They issue loads and stores to device addresses, they program PCI configuration space, and they wait on interrupts. On x86 they also use port I/O. On Arm they use MMIO and a GICv3.

When the guest stores to a device address, that store is not a RAM write. The hypervisor intercepts it and turns it into a call on a device model. The model updates its registers, may schedule work, and may raise an interrupt later. From the guest's point of view it just wrote a doorbell.

MX splits that work across a bus, a factory, and the device models the machine asked for.

The factory

A machine description is a list of device instances, not a pile of hardcoded objects. Each instance names a type and its parameters. The factory turns that instance into bus mappings, PCI functions, and lifecycle hooks. The registry owns the types a platform supports and rejects parameters a type does not accept.

Platform interconnect is assembled once, not per device. The x86 interrupt fabric and the AArch64 GICv3 live on the machine, and every device talks to them. A disk controller should not have to invent the interrupt controller it uses.

Three ways to attach a device

Wrappers look like real hardware. AHCI, NVMe, XHCI, a GICv3, a PL031 RTC, and the rest of the board's IP sit here. The guest loads the driver it would load on a physical machine. Identities come from the machine profile, not from a virt-shaped PCI ID unless you asked for one.

Virtio is the OASIS Virtual I/O Device contract. The guest knows it is talking to a paravirtualised device. MX implements the modern PCI transport and the split virtqueue, then layers block, net, entropy, console, sound, and virtio-gpu on top. The MX guest-additions control channel is not a virtio device; it publishes its own PCI identity and reuses the queue machinery.

Passthrough assigns a real host USB or PCIe device into the guest. The next two articles cover graphics and passthrough in their own right. The important point here is that passthrough is still a device instance: it has a factory, an IOMMU policy, and a lifecycle. It is not a hole punched in the bus.

DMA and isolation

Devices bus-master. A disk or a GPU that can write physical addresses will write them. On a physical machine an IOMMU sits between that device and RAM. MX keeps the same shape.

Every DMA path goes through a translator. That is the IOMMU policy for the VM, including the VT-d compatible mode used with PCIe passthrough, and the IOMMU the guest's own board model already has. The guest sees the IOMMU that board would have. A device cannot walk off into host pages the guest was not given.

Time and interrupts

Guest timers are wall clock. Host-side work is not taken out of the guest's deadlines.

Interrupts follow the platform controller. Virtio MSI, x86 INTx, and GICv3 PPIs and SPIs are different wires. A virtio disk that raises the wrong class of interrupt will hang a boot as surely as a silent doorbell.