series · in progress
KVM Virtualization on ARM64
Building the KVM/QEMU/libvirt stack from the silicon up on ARM64, with real terminal output from a Raspberry Pi 5 — because almost every KVM guide assumes x86.
Search for a KVM guide and you will find x86. The commands assume Intel VT-x, the troubleshooting assumes an i440FX machine type, and the moment something fails on aarch64 you are on your own with a mailing list thread from 2019.
This series is the ARM64 version. Every command is aarch64-native and every block of terminal output is real, captured from a Raspberry Pi 5 (8 GB) running Raspberry Pi OS Bookworm on kernel 6.12. Where ARM64 does something genuinely different from x86, that difference is the point rather than a footnote.
It is written to be read in order. The concepts come first, each one setting up the question the next one answers, and the hands-on work starts only once there is a model to hang it on. If you already run VMs on x86 and just want the ARM64 specifics, Part 2 is where the terminal opens.
More parts are in progress.
Start reading: What a Hypervisor Is, and Where KVM Fits (Type-1 vs Type-2) →
Part 1 How the stack works
The mental model, built in causal order: what a hypervisor is, what the CPU contributes, and why the stack has three pieces instead of one.
- 1.1 What a Hypervisor Is, and Where KVM Fits (Type-1 vs Type-2)
The Type-1 vs Type-2 split is the first thing every virtualization tutorial teaches, and KVM breaks it. Here's why that's interesting rather than annoying.
- 1.2 Why KVM Needs the CPU: ARM64 EL2, VHE, and the Virtualization Extension
KVM is a kernel module, but virtualization is a hardware feature. Understanding how those two relate is where most people's mental model of KVM breaks.
- 1.3 KVM vs QEMU vs libvirt: Who Does What
Three pieces, one running VM. Each exists because of a specific gap the layer below it leaves open — which is a better way to learn them than three definitions.
- 1.4 How QEMU Emulates Hardware: Device Models, MMIO, and TCG
Every device your guest sees is C code responding to memory addresses. Once you see the trick, QEMU stops being mysterious and its performance behaviour becomes predictable.
- 1.5 What ioctl(KVM_RUN) Does: The VM Exit Loop Explained
One system call, looped forever, is what running a virtual machine physically is. Here's what happens inside it — and why some VM exits cost far more than others.
- 1.6 Why VirtIO Is Faster Than Emulated Devices: Virtqueues and vhost-net Explained
Emulated devices are slow because they faithfully imitate hardware that was never designed for software. VirtIO throws that away and lets the guest cooperate instead.
Part 2 Getting a guest running
Hands-on from here. Verifying the host, installing the userspace stack, and the four undocumented failures between a correct virt-install command and a booting guest.
- 2.1 How to Check KVM Is Enabled on Raspberry Pi 5 (/dev/kvm, lsmod, dmesg)
Three commands confirm your host can run accelerated VMs — and one of them returns nothing on a Raspberry Pi, for a reason that confuses a lot of people.
- 2.2 Installing the KVM Stack on Raspberry Pi OS: What Each Package Does
Nine packages, three layers. Then virt-host-validate reports four warnings and three failures on a healthy system — here's how to triage every line.
- 2.3 Fixing virt-install on arm64: Security Violation, dnsmasq Port 53, and the qemu:///session Trap
Four failures stand between a correct virt-install command and a booting arm64 guest. None of them are documented well, and the error messages point away from the causes.
- 2.4 virt-install Explained: Every Flag for an arm64 Guest
Twelve flags look like a lot to memorize. They're answers to seven questions — and once you know the questions, you can write the command for any guest from scratch.