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) →
coming next 3.5 How a VM Plugs Into the Host's Network: interface, TAP, and virbr0, on 16 November 2026. The RSS feed will carry it.
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)
What a hypervisor is, why KVM does not fit the usual Type 1 versus Type 2 categories, and what it inherits from being part of the Linux kernel.
- 1.2 Why KVM Needs the CPU: ARM64 EL2, VHE, and the Virtualization Extension
KVM is part of the Linux kernel, but virtualization is a hardware feature. How those two relate is where most people's understanding of KVM breaks down.
- 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, 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 predictable.
- 1.5 What ioctl(KVM_RUN) Does: The VM Exit Loop Explained
One system call, ioctl(KVM_RUN), repeated in a loop, is what running a virtual machine physically is. This post looks closely at it, and at the VM exit loop.
- 1.6 Why VirtIO Is Faster Than Emulated Devices: Virtqueues and vhost-net Explained
Emulated devices are slow because they faithfully imitate hardware 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 is how to read every line.
- 2.3 Fixing virt-install on arm64: Security Violation, dnsmasq Port 53, and the qemu:///session Trap
The virt-install command in most ARM64 guides is correct, and it still fails, for four reasons that come from defaults rather than the command. Here is each.
- 2.4 virt-install Explained: Every Flag for an arm64 Guest
The command that builds a Debian guest on a Raspberry Pi 5 has 14 options, answering seven questions. Learn the questions, and write the next command yourself.
Part 3 Inside the VM definition
What a libvirt VM actually is: one XML document, the firmware it boots, the console and network it plugs into, and the commands that move it between states.
- 3.1 What a libvirt VM Really Is: The XML File Behind Every Tool
Behind virt-install, virsh and virt-manager, a libvirt VM is one XML document that points to its disk and firmware files. Here is what that means.
- 3.2 How a Computer Boots Before Any OS Exists: BIOS, UEFI, and GPT
At power-on a CPU knows nothing about disks or files. Firmware fills that gap, and its two generations explain most of what is confusing about booting.
- 3.3 Why a VM Needs Two Firmware Files: AAVMF and OVMF Explained
A VM has no motherboard, so its UEFI firmware comes as files: one program shared by every VM, and one settings file per VM. Mix them up and a VM stops booting.
- 3.4 Reading a libvirt Domain XML: The 20 Lines That Are Actually Your Decisions
virsh dumpxml prints 180 lines for one small VM. About twenty of them record choices you made; the rest are defaults. Here is how to tell which is which.