macOS 26.6.2 (Apple Silicon): aarch64 HVF guest fails most boots — firmware reset loop or vCPU hard lockup; pristine pre-update VM reproduces

[locupleto]

Describe the issue

After the host was updated from macOS 26.5.2 to 26.6.2 (25G83, xnu-12377.161.1), an aarch64 Linux VM (QEMU backend, -accel hvf, -cpu host, -machine virt, EDK2 + systemd-boot, Arch Linux aarch64) that had been running for days fails most boots. Nothing in the VM changed; the same failure reproduces on a byte-verified Time Machine restore of the entire .utm bundle from before the macOS update (qcow2, efi_vars.fd, config.plist all compared identical to the backup), so guest state, NVRAM and VM config are ruled out.

Three presentations, all in a single QEMU process:

1. Firmware-stage reset loop (most common now): EDK2 loads systemd-boot, the menu countdown expires, the machine resets before the kernel prints a single byte, and this repeats indefinitely. QEMU sits at ~200 % CPU. Serial console, verbatim, repeating:

   BdsDxe: loading Boot0003 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x6,0x0)
   BdsDxe: starting Boot0003 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x6,0x0)
           Arch Linux (aarch64)      Reboot Into Firmware Interface      Boot in 5s.
   BdsDxe: starting Boot0003 "UEFI Misc Device 2" ...
   

   Zero occurrences of Booting Linux across 11+ consecutive cycles in the captures. UTM 5 shows "Display output is not active." while this happens.

2. vCPU hard lockup early in kernel boot (~5 s or ~16-20 s of guest time), kernel 7.1.8 and 7.1.11 alike:

   [   16.237597] watchdog: CPU2: Watchdog detected hard LOCKUP on cpu 3
   [   16.237728] Sending NMI from CPU 2 to CPUs 3:
   (nothing follows)
   

   The target vCPU never answers the NMI. kick_all_cpus_sync() from the BPF JIT is where a dead vCPU first becomes visible, but the JIT is the victim, not the cause; maxcpus=1 in the guest did not help.

3. The same lockup after sshd is already answering (~30-60 s), QEMU at ~100 %.

The loop/lockup is probabilistic per cycle rather than deterministic. Measured today on the pristine restored VM, 4 vCPUs:

UTM	QEMU	Result
4.7.5	10.0.2	~1 boot in 3 reaches userspace; kernel-stage lockups seen
5.0.4	10.0.12	3 boots in 4 reach userspace (after 5-16 firmware cycles, 31-83 s); no kernel-stage lockup seen in 4 boots

Ruled out by experiment: host CPU load, page-cache state (14 GB pre-warm), vCPU count (8, 4, 1 all fail), virtio-gpu-gl-pci vs virtio-gpu-pci (identical loop), guest kernel version (7.1.8 and 7.1.11), NVRAM (parsed; identical to pre-update backup), UTM freshly launched vs long-running. Host has 64 GB, no swap, no memory pressure.

Before the 26.6.2 update the only failure was a single wedge on the first VM start after a host reboot, with every later start clean (7/7 and 9+/9+ over two days on 26.5.2). After it, most starts fail on a host that has been up for hours.

Configuration

• UTM Version: 4.7.5 (QEMU 10.0.2) and 5.0.4 (QEMU 10.0.12) — both affected, 5.0.4 less so
• macOS Version: 26.6.2 (25G83). Worked on 26.5.2.
• Mac Chip: M1 Ultra (Mac Studio), 64 GB

Crash log
No crash — QEMU keeps running, pinned at ~200 % (firmware loop) or ~100-400 % (lockup).

Debug log
Serial console captures (-chardev pty … -serial chardev:term0) are quoted above; full captures available on request. The -2700/Operation not available AppleScript errors sometimes seen from utmctl are unrelated noise from a launcher script.

Upload VM
config.plist inline (no drive image; it contains nothing personal beyond a MAC address):

config.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Backend</key>
	<string>QEMU</string>
	<key>ConfigurationVersion</key>
	<integer>4</integer>
	<key>Display</key>
	<array>
		<dict>
			<key>DownscalingFilter</key>
			<string>Linear</string>
			<key>DynamicResolution</key>
			<true/>
			<key>Hardware</key>
			<string>virtio-gpu-gl-pci</string>
			<key>NativeResolution</key>
			<false/>
			<key>UpscalingFilter</key>
			<string>Nearest</string>
		</dict>
	</array>
	<key>Drive</key>
	<array>
		<dict>
			<key>Identifier</key>
			<string>CF7EAC9A-93F7-49AB-969B-BDB27E9E5C89</string>
			<key>ImageName</key>
			<string>CF7EAC9A-93F7-49AB-969B-BDB27E9E5C89.qcow2</string>
			<key>ImageType</key>
			<string>Disk</string>
			<key>Interface</key>
			<string>VirtIO</string>
			<key>InterfaceVersion</key>
			<integer>1</integer>
			<key>ReadOnly</key>
			<false/>
		</dict>
	</array>
	<key>Information</key>
	<dict>
		<key>IconCustom</key>
		<false/>
		<key>Name</key>
		<string>Omarchy ARM</string>
		<key>UUID</key>
		<string>D52F1204-F118-4B55-B41A-6DF16836B14B</string>
	</dict>
	<key>Input</key>
	<dict>
		<key>MaximumUsbShare</key>
		<integer>3</integer>
		<key>UsbBusSupport</key>
		<string>3.0</string>
		<key>UsbSharing</key>
		<false/>
	</dict>
	<key>Network</key>
	<array>
		<dict>
			<key>Hardware</key>
			<string>virtio-net-pci</string>
			<key>IsolateFromHost</key>
			<false/>
			<key>MacAddress</key>
			<string>46:6E:26:C0:34:C6</string>
			<key>Mode</key>
			<string>Shared</string>
			<key>PortForward</key>
			<array/>
		</dict>
	</array>
	<key>QEMU</key>
	<dict>
		<key>AdditionalArguments</key>
		<array/>
		<key>BalloonDevice</key>
		<false/>
		<key>DebugLog</key>
		<false/>
		<key>Hypervisor</key>
		<true/>
		<key>PS2Controller</key>
		<false/>
		<key>RNGDevice</key>
		<true/>
		<key>RTCLocalTime</key>
		<false/>
		<key>TPMDevice</key>
		<false/>
		<key>TSO</key>
		<false/>
		<key>UEFIBoot</key>
		<true/>
	</dict>
	<key>Serial</key>
	<array>
		<dict>
			<key>Mode</key>
			<string>Ptty</string>
			<key>Target</key>
			<string>Auto</string>
		</dict>
	</array>
	<key>Sharing</key>
	<dict>
		<key>ClipboardSharing</key>
		<true/>
		<key>DirectoryShareMode</key>
		<string>WebDAV</string>
		<key>DirectoryShareReadOnly</key>
		<false/>
	</dict>
	<key>Sound</key>
	<array>
		<dict>
			<key>Hardware</key>
			<string>intel-hda</string>
		</dict>
	</array>
	<key>System</key>
	<dict>
		<key>Architecture</key>
		<string>aarch64</string>
		<key>CPU</key>
		<string>default</string>
		<key>CPUCount</key>
		<integer>4</integer>
		<key>CPUFlagsAdd</key>
		<array/>
		<key>CPUFlagsRemove</key>
		<array/>
		<key>ForceMulticore</key>
		<true/>
		<key>JITCacheSize</key>
		<integer>0</integer>
		<key>MemorySize</key>
		<integer>16384</integer>
		<key>Target</key>
		<string>virt</string>
	</dict>
</dict>
</plist>

Happy to run any diagnostic you want against this VM; the reproduction is reliable within a few starts.