Machine type (-M) selects the emulated board, determining CPU architecture, memory map, available peripherals, and which devices are accessible. Different boards have different capabilities.

qemu-system-arm -M versatilepb -kernel Image      # ARM Versatile PB
qemu-system-arm -M virt -kernel Image             # Generic virtual machine
qemu-system-riscv64 -M virt -kernel Image         # RISC-V virtual machine
qemu-system-arm -M raspi2                         # Raspberry Pi 2 (partial)

Versatile (versatilepb) is the classic choice for ARM cross-compilation testing. Well-supported, stable, and includes UART, timer, and interrupt controller. Good for kernel and bootloader testing.

Virt is a generic virtual machine for each architecture (ARM, AARCH64, RISC-V). Defined by QEMU rather than mimicking real hardware. Simplest for testing OS kernels; no need to model real board quirks. Recommended for new projects.

Raspi2 emulates Raspberry Pi 2 hardware. Partial support means some peripherals work, others don't. Useful for Raspberry Pi-specific testing but slower and less stable than virt.

List available machines:

qemu-system-arm -M help       # all ARM boards
qemu-system-riscv64 -M help   # all RISC-V boards

Each machine defines:

• CPU type(s) and count
• RAM size and address space
• Peripherals (UART, timer, interrupt controller, SPI, I2C, etc.)
• Device tree (if applicable)
• Clocks and power domains

For cross-compilation testing, choose based on your target board. If exact hardware isn't available in QEMU, use virt instead—it's close enough for driver and kernel testing.

The device tree (.dtb file) depends on the machine type. A versatilepb.dtb won't work on a virt machine and vice versa. Always use the matching .dtb for the -M board you select.