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

**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

Backend
QEMU
ConfigurationVersion
4
Display


DownscalingFilter
Linear
DynamicResolution

Hardware
virtio-gpu-gl-pci
NativeResolution

UpscalingFilter
Nearest


Drive


Identifier
CF7EAC9A-93F7-49AB-969B-BDB27E9E5C89
ImageName
CF7EAC9A-93F7-49AB-969B-BDB27E9E5C89.qcow2
ImageType
Disk
Interface
VirtIO
InterfaceVersion
1
ReadOnly



Information

IconCustom

Name
Omarchy ARM
UUID
D52F1204-F118-4B55-B41A-6DF16836B14B

Input

MaximumUsbShare
3
UsbBusSupport
3.0
UsbSharing


Network


Hardware
virtio-net-pci
IsolateFromHost

MacAddress
46:6E:26:C0:34:C6
Mode
Shared
PortForward



QEMU

AdditionalArguments

BalloonDevice

DebugLog

Hypervisor

PS2Controller

RNGDevice

RTCLocalTime

TPMDevice

TSO

UEFIBoot


Serial


Mode
Ptty
Target
Auto


Sharing

ClipboardSharing

DirectoryShareMode
WebDAV
DirectoryShareReadOnly


Sound


Hardware
intel-hda


System

Architecture
aarch64
CPU
default
CPUCount
4
CPUFlagsAdd

CPUFlagsRemove

ForceMulticore

JITCacheSize
0
MemorySize
16384
Target
virt

```

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

Start by reproducing the failure with the supplied config.plist, serial console captures, and the listed UTM/QEMU versions on macOS 26.6.2, then compare against macOS 26.5.2 if available. Done means identifying the host or HVF-related regression and establishing a reliable fix or confirmed workaround for the firmware reset loop and vCPU lockups.

Written by the indexing model from the issue text.