Repository navigation
M6: macOS, Windows, Arm, RISC-V #7
Description
The seventh milestone in spec/23-milestones.md. macOS, Windows, Arm and RISC-V, and the desktop.
Why
Developers on Apple silicon and Windows are the second largest group, and they arrive with a desktop, so the UIs arrive with them.
Accelerators
-
ruvm-accel-hvfon Apple silicon including vGIC and nested virtualization (accel-hvf: port the Hypervisor.framework accelerator #221, cross-checked only, hardware runs in M6: run HVF, WHPX and Arm KVM on real hardware #227) -
ruvm-accel-whpxon Windows (accel-whpx: port the Windows Hypervisor Platform accelerator #223, cross-checked only, hardware runs in M6: run HVF, WHPX and Arm KVM on real hardware #227)
Machines
- arm
virtwith GICv3, ITS, SMMUv3, PCIe and ACPI, andsbsa-ref - riscv
virtwith AIA, PCIe and ACPI - The Arm GIC in userspace and in kernel under KVM on AArch64 Linux (accel-kvm: build on AArch64 Linux and add the in-kernel Arm vGIC #226, cross-checked only, hardware runs and the arm virt wiring in M6: run HVF, WHPX and Arm KVM on real hardware #227)
JIT
- RISC-V guest including RVV and the H extension
- riscv64 host backend
UI and audio
- Cocoa, GTK, SDL, VNC and the D-Bus display
- Audio backends for those hosts
Exit criterion
- On macOS AArch64, a Linux aarch64 guest and Windows 11 on Arm boot under HVF with virtio-gpu and graphical output.
- On Windows x86-64, a Linux guest boots under WHPX.
- A RISC-V Linux guest boots under TCG on every tier 1 host.
- QEMU's qtest suites for aarch64 and riscv64 pass at QEMU's rate for these machines, and
tests/tcgfor riscv64 passes.
Depends on
M4.
Spec
spec/06-accelerators.md, spec/09-guest-targets.md, spec/11-machines-and-firmware.md, spec/15-net-chardev-ui-audio.md.
Activity
tamnd commentedon Oct 7, 2026
#157 is merged, the first M6 slice. There is now a RISC-V guest on TCG (RV64GC with M, S and U modes, Sv39/48/57 paging, PMP and the Zb* extensions) and a riscv
-M virtboard with the PLIC, ACLINT, UART, virtio-mmio, fw_cfg, RTC, the test finisher, OpenSBI loading and a device tree.All five riscv64 system tests from QEMU's tests/tcg (issue1060, test-mepc-masking, doubletrap, interruptedmemory, test-crc32) exit with code 0 with QEMU's own options.
No boxes ticked yet, since RVV, the H extension, AIA, PCIe and ACPI are still missing. Next is a RISC-V Linux kernel booting to a shell on an x86-64 host and on an aarch64 host. After that I'll compare the device tree against real QEMU once the server's QEMU 11.1 build finishes.
tamnd commentedon Oct 7, 2026
#158 is merged. A Debian 6.12 riscv64 kernel now boots to a busybox shell under TCG on
-M virtwith OpenSBI, at 1, 2 and 4 vCPUs, on an x86-64 host and on an aarch64 host (Apple M4 in colima). Median time to the prompt is 13.9 to 19.9 s on a shared x86-64 server and 8.3 to 10.9 s on the M4. Getting there fixed a lock order deadlock that hit every boot with more than one vCPU. That covers exit criterion 3 for the Linux hosts. RVV and the H extension are next.Release 0.4.1 (#159)
tamnd commentedon Oct 7, 2026
Released v0.4.1, which includes #157 and #158.
tamnd commentedon Oct 7, 2026
#161 is in. The riscv guest now has the vector extension (V, the Zve subsets, Zvfh and the bf16 vector extensions) with the full vector crypto set, and the H extension with two-stage translation, the hypervisor CSRs, HLV, HLVX and HSV, and VS interrupt routing. H is on by default and V is opt in with
-cpu rv64,v=on, both as in QEMU 11.1. A bare metal H test prints the same 251 lines on ruvm and QEMU, and Linux reports rv64imafdch at-smp 2. Still left on riscv virt: guest external interrupts and AIA, the PCIe host bridge, ACPI,-cpu max, and closing the 1.7x gap to QEMU on the boot to a shell.tamnd commentedon Oct 7, 2026
Released 0.4.2 (https://github.com/tamnd/ruvm/releases/tag/v0.4.2) with the RVV and H work from #161. Next on riscv virt: the PCIe host bridge,
-cpu maxand AIA.tamnd commentedon Oct 7, 2026
#163 is in. riscv virt now has QEMU's generic PCIe host bridge (gpex) at the same addresses as QEMU 11.1, and
-device virtio-{blk,rng,serial}-pciand-drive if=virtiowork behind it. Against QEMU on the same command line the device tree differs only in rng-seed, the config space of every function is byte for byte the same, and Linux puts the virtio devices on the same PLIC lines. The "riscv virt with AIA, PCIe and ACPI" box stays open until AIA and ACPI land.-cpu maxand the named riscv CPU models are next.76 remaining items
tamnd commentedon Oct 14, 2026
Merged #305, which adds query-cpu-model-expansion on Arm and takes
sve, thesve<N>vector lengths,pmuandaarch64=onin-cputhe way QEMU does, including length maps with gaps such as the onesve512=ongives. 330 expansion requests under 8-cpusettings, with TCG and with the qtest accelerator, and the startup errors of 19-cpustrings gave the same answers as QEMU 11.1. The qtest counts are unchanged at 73 of 447 on aarch64 and 79 of 241 on riscv64, because arm-cpu-features still stops atgic-version=max, which is next.tamnd commentedon Oct 14, 2026
#307 merged:
gic-versionon Arm virt now takesmaxandhostlike QEMU 11.1, andx-5replaces5. Under TCG and qtestmaxpicks GICv3, andhostfails with "gic-version=host requires KVM". arm-cpu-features now passes 3/3 against ruvm, the same as QEMU.Counts in docs/qtest-status.md: aarch64 passes 76 of 447 test cases, riscv64 passes 79 of 241.
Next: device vmstate for the Arm virt board (pl011, pl031, pl061, gpio-key), the first step toward migration-test on virt.
tamnd commentedon Oct 14, 2026
#310 merged: the PL011, PL031, PL061 and GPIO key of Arm
virtnow save and load thepl011,pl031,pl061andgpio-keysections QEMU 11.1 sends, checked byte for byte against a stream QEMU wrote forvirt. The board does not register them yet, so no count changes: aarch64 76 of 447, riscv64 79 of 241.Next, in small PRs: the migration stream with the
timer, RAM andglobalstatesections onvirt, then the CPU state, then the GIC, then the devices. Separately, a docs PR moves the qmp-cmd-test rows to the stock test against a QEMU build with VNC.tamnd commentedon Oct 14, 2026
#311 merged.
virton TCG now migrates with QEMU 11.1'stimer,ramandglobalstatesections and the configuration section (virt-11.1, target-page-bits 12, uuid). The RAM block list hasmach-virt.ram,virt.flash0andvirt.flash1in QEMU's order, and QEMU's analyze-migration.py reads the stream ruvm writes. The PL011, PL031, PL061 and GPIO key from #310 are not registered with the board yet.Counts are unchanged: aarch64 76 of 447, riscv64 79 of 241. migration-test still stops at its first case because ruvm refuses
x-ignore-shared. That is the next PR.tamnd commentedon Oct 14, 2026
#314 merged: migration now takes the
x-ignore-sharedcapability, and with it each RAM block in the setup list carries its guest address, as QEMU 11.1 writes it. I compared the configuration section and the block list of avirtstream from ruvm with one from QEMU 11.1 byte for byte; they match apart from the three/rom@etcACPI blocks QEMU has and ruvm does not have yet.In migration-test the analyze-script case now passes. The next case (multifd) still hangs, because the destination runs its vCPUs from reset until the CPU state slice lands, which is what I am on now.
Counts: aarch64 77 of 447, riscv64 79 of 241.
tamnd commentedon Oct 14, 2026
#315 merged: the qmp-cmd-test rows now come from the stock test of a second QEMU 11.1 build with
--enable-vnc --enable-pixman, instead of a patched copy of the test. That build's test passes 61 of 61 against its own QEMU and 64 of 64 against ruvm on both targets. The three extra cases are the TPM queries, which ruvm answers and which QEMU built with--without-default-featuresleaves out of its schema.Counts: aarch64 124 of 449, riscv64 126 of 243.
tamnd commentedon Oct 14, 2026
#320 merged:
virton TCG now migrates its vCPUs in QEMU 11.1'scpu_commonandcpusections, with the same 362 register indexes and the same subsections QEMU sends formax. The streams still differ in a few reset values and in the ID registers, as written in docs/qtest-status.md.Counts are unchanged: aarch64 124 of 449 and riscv64 126 of 243. migration-test stays at 1 of 12 on the debug build. Its multifd case now moves the guest and the destination goes on running, but a debug build is too slow for the 480 s timeout, so I will count it with a release build. The GICv3 and ITS sections are next.
tamnd commentedon Oct 14, 2026
#322 merged:
virton TCG now migrates the GICv3 and its ITS in QEMU 11.1'sarm_gicv3andarm_gicv3_itssections, with QEMU's section ids and stream order. For-cpu maxwith-Sboth sections match QEMU field for field apart from the NMI subsections, which QEMU sends because itsmaxhas FEAT_NMI. A guest migrated over TCP between two ruvm processes keeps running on the destination.Counts are unchanged: aarch64 124 of 449 and riscv64 126 of 243. migration-test stays at 1 of 12 until I count it with a release build. Next is the generic timer counter, which should follow the migrated virtual clock as QEMU's does.
tamnd commentedon Oct 14, 2026
#324 merged: the Arm generic timers and the PMU cycle counter now count the board's virtual clock, which stops while the VM is stopped and which the
timersection carries. A Linux guest moved with migration goes on with its uptime on the destination, as it does under QEMU 11.1. migration-test was counted with a release build this time: 5 of 12 pass (analyze-script, multifd/tcp/plain/zlib, multifd/tcp/plain/cancel, multifd/tcp/uri/plain/none, multifd/file/mapped-ram/dio). postcopy/plain fails because ruvm does not take thepostcopy-blocktimecapability yet, and the test bails out there. qtests now pass: aarch64 128 of 449, riscv64 126 of 243. Next ispostcopy-blocktime, so the postcopy cases can run.tamnd commentedon Oct 14, 2026
#325 merged: ruvm takes the postcopy-blocktime capability and reports the blocktime and latency of the destination as QEMU 11.1 does. postcopy/plain now passes, so migration-test gives 6 of 12 on aarch64. The next case, postcopy/recovery/plain, fails on migrate-pause, as ruvm has no postcopy recovery yet. Counts with a release build on server2: aarch64 129 of 449, riscv64 126 of 243. docs/qtest-status.md has the details.
tamnd commentedon Oct 14, 2026
#328 merged:
virtnow migrates its PL011 UARTs, PL031 RTC, PL061 GPIO controllers and GPIO power key, in the order QEMU 11.1 creates them, and keeps the section ids of the PCI host, ACPI GED, fw_cfg and ACPI table sections it does not send yet. #327 landed between my checks and the merge, so I rebuilt the merged main (23f8031) on server2 and ran the compare again: against QEMU 11.1 the section names, instances and ids match for the default board, with two-serialand withsecure=on, and the four device sections match field for field apart from the time the RTC holds. migration-test on aarch64 stays at 6 of 12, failing at postcopy/recovery/plain on migrate-pause. The other counts are unchanged from the last full run: aarch64 129 of 449, riscv64 126 of 243. Next: the two pflash_cfi01 sections.tamnd commentedon Oct 14, 2026
#335 merged: virt now migrates its two CFI01 flashes in QEMU 11.1's
pflash_cfi01sections (ids 3 and 4), with thepflash_cfi01_blk_writesubsection while a write to buffer is in progress. Against QEMU 11.1 with a raw guest, the flash sections match byte for byte in status mode and in a stopped write to buffer, a ruvm destination passes the same state on, and a destination with a flash image writes the migrated contents back. Checked on 01b3b12 plus the diff, which is the merged commit.Counts are unchanged: aarch64 129 of 449, riscv64 126 of 243. migration-test on aarch64 stays at 6 of 12, and a Linux guest migrated between two ruvm instances keeps running.
Also #334 fixes
x86::tests::vfio_pci_properties, which #330 broke on Linux.Next: the PCI host sections (
gpex_root,PCIHost,PCIBUS), thenfw_cfgand the ACPI blocks.tamnd commentedon Oct 14, 2026
#338 is merged (debd8d2).
virtnow migrates its PCI host in QEMU 11.1's0000:00:00.0/gpex_root,PCIHostandPCIBUSsections. They match QEMU byte for byte with one serial port, with two, withsecure=on, and after a raw guest has run for a second. A Linux guest moved mid-run keeps going on the destination with its uptime counting on. The remaining virt sections arefw_cfgandvirt_acpi_build, plus the PCI devices and the/rom@etcblocks.Counts are unchanged: aarch64 129 of 449, riscv64 126 of 243, and migration-test on aarch64 6 of 12 (release build).
tamnd commentedon Oct 14, 2026
#340 merged as ad204ac. virt on TCG now migrates
fw_cfg(with thefw_cfg/acpi_mrsubsection, also on q35) andvirt_acpi_build, and both match QEMU 11.1 byte for byte with one and two serials,secure=onandacpi=off. Without firmware the stream now has every section QEMU 11.1 sends forvirt.Counts are unchanged: aarch64 129 of 449, riscv64 126 of 243, migration-test 6 of 12 on a release build.
Checks rerun on ad204ac itself on server2: clippy -D warnings clean for hw-core, machine-arm, machine-x86 and system; ruvm-system lib 113 passed, hw-core 44 passed, machine-arm lib 36 and tests/virt 42 passed, machine-x86 lib migration 35 passed.
tamnd commentedon Oct 14, 2026
#342 merged as 8fb1fee. virt on TCG now migrates its ACPI GED in QEMU 11.1's
acpi-gedsection with theacpi-ged/memhpsubsection. With-biosthe section matches QEMU's, and so do the ids offw_cfg,virt_acpi_buildandglobalstateafter it. So with or without firmware, the stream now has every section QEMU 11.1 sends forvirt. The GED and memory hotplug descriptions now live inruvm_hw_acpi::vmstate, shared with microvm.The counts haven't changed: aarch64 129 of 449, riscv64 126 of 243, and migration-test 6 of 12 on a release build. postcopy/recovery/plain still fails first.
I ran these on e7c7db9 plus the change, which is the tree that merged:
acpi=off.The ship hook ran on the same tree and passed: