Boot NetBSD on QEMU's microvm machine type, and report where setup time goes

[jacob-carlborg]

The consumer-side half of netbsd-builder#11: read the new image bundle, and add a variant: microvm that boots the kernel it carries on QEMU's microvm machine type.

Measured

From CI (Test the microvm variant), NetBSD 11.0 x86-64: the action's whole Start VM step — download, unpack, boot, wait for sshd, synchronize files — takes 10 seconds, on a 268 MiB image. The guest's own kernel boot, from its console, is 221–347 ms.

These numbers were measured separately, against master, and are not produced by the CI matrix:

	master	variant: microvm
time to a reachable sshd	~20.5s	3.2s
total setup	34.4s	18.7s
image download	497 MiB	265 MiB

The Timings breakdown of each setup phase, added here, is how they were measured and how the remaining time can be attributed. The table goes to the log; the same numbers go to the debug log as JSON, for comparing runs mechanically.

Opt-in

microvm is a variant, not the new default, because it changes the hardware the guest sees: the root disk arrives as ld0 (virtio-blk) rather than sd0 (vioscsi), there is no PCI bus and no ACPI to inspect, and uname -v names a MICROVM kernel. None of that stops a guest booting, which is why applying it silently would be the dangerous option — a job that reads hardware would fail for a reason its author has no way to attribute.

- uses: cross-platform-actions/action@v1
  with:
    operating_system: netbsd
    version: '11.0'
    variant: microvm

Unset means default, which boots exactly as before, so no existing workflow changes. Asking for microvm where it cannot be satisfied — an image bundle with no kernel, a hypervisor archive with no qboot, or NetBSD/VAX, which runs on SIMH — is an error naming what is missing, rather than a quiet fall back to the slower path.

That strictness earned its keep immediately. The VM used to be constructed before the image bundle was unpacked, so the kernel was not yet on disk when the boot path was chosen — feature detection would have said "no kernel" on every fresh run and silently booted through the firmware, with CI green throughout. Disk preparation now happens before the VM is created, and two jobs cover it: one boots the variant and checks the guest really came up that way, the other asks for it on 10.1 — which predates the MICROVM kernel configuration — and requires the action to fail.

No breaking change for custom images

The image bundle itself is not opt-in: every NetBSD image this action downloads is now a .tar.zst holding a raw disk.img and, where the platform has one, a kernel. That is where the download savings come from, on both variants.

An image supplied through image_url is unaffected, because nothing assumes the new format. Which of the three formats NetBSD has shipped a file is comes from its magic bytes, so a qcow2 or a bare .img.zst from an earlier netbsd-builder release still boots. And while the published images accept a login with no credential — so no SSH key is generated and no resources disk built for them — a custom image still gets both, since it may have been built from a release that expects the key there and there is no way to tell from the outside.

Neither of those was covered before: Test custom VM image uses OpenBSD, so custom NetBSD images had no CI at all. Test a custom NetBSD image from before the bundle boots v0.7.0's netbsd-11.0-x86-64.qcow2 and closes that gap.

Merging

The prerequisites are done:

1. netbsd-builder#11 — merged.
2. netbsd-builder v1.0.0 — released, with a bundle for every version and architecture the CI matrix boots.
3. netbsd: in src/version.ts — pinned to v1.0.0.

Ready to merge. Afterwards, netbsd-builder's Test Image step needs its uses: pinned back from this branch to @master.

[jacob-carlborg]

CI on d87032f: 82 of 83 jobs pass, including build (with the dist check) and all 11 NetBSD jobs.

The one red job, Test without environment variables, is a FreeBSD 13.0 guest panicking during early kernel init, twice with the same fault address:

FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3076000
panic: page fault
Uptime: 1s

Not caused by this branch. Building the QEMU command for a FreeBSD x86-64 guest on master and on this branch gives one difference, the host address the SSH port forward binds to:

-  user,id=user.0,hostfwd=tcp::2847-:22
+  user,id=user.0,hostfwd=tcp:127.0.0.1:2847-:22

Machine type, CPU, devices, drives and firmware are identical, so nothing here changes what the guest boots on — and the guest is dead one second in, long before sshd or the port forward matter.

It also looks like a property of the runner rather than of the version: FreeBSD x86-64 13.0 in the matrix boots the same image and passed in the same run. Leaving it alone rather than papering over it here.

---

Generated by Claude Code

[jacob-carlborg]

Updating the numbers in my earlier comment, since the branch has changed since (microvm is now variant: microvm rather than the default).

CI on 82c1dff: 84 of 85 jobs pass, including build with the dist check, all 11 NetBSD jobs, and the two new ones:

• Test the microvm variant — boots 11.0 x86-64 with variant: microvm and checks the guest really came up that way: uname -v reports MICROVM, virtio arrives over MMIO, ld0 at virtio is present, and neither sd0 at nor pci0 at is. Console confirms qboot's MP table and a 225 ms kernel boot.
• Test the microvm variant on an image without a kernel — asks for the variant on 10.1, which predates the MICROVM kernel configuration, and requires the action to fail.

Both FreeBSD 13.0 jobs passed on this run, having panicked at 1s uptime on the previous ones. Same code, different runners, which supports the reading in my earlier comment that it is a property of the host rather than of the version.

The one red job is Test reboot shell on Haiku, where the guest kernel panics inside its own TCP stack as sshd exits during the reboot:

PANIC: bound endpoint 0xffffffff9e3aea00 not in hash!
Thread 145 "sshd"
 5 ... <tcp> EndpointManager::Unbind(TCPEndpoint*) + 0xa7
 6 ... <tcp> TCPEndpoint::~TCPEndpoint() + 0x58
23 ... thread_exit + 0xd77

Intermittent, and reproduced on master's own code on today's runners, so not from this branch. Not re-running it again.

---

Generated by Claude Code