Windows 11 ARM64 install hangs at "starting BootXXXX" on UTM 5.0.5 (M4 Max) — reproducible across GPU/storage/accel/TPM permutations

### Environment

* **UTM:** 5.0.5 (Beta), installed via `brew install --cask utm@beta`
* **macOS:** 26.6.2 (Build 25G83)
* **Hardware:** Apple M4 Max (MacBook Pro)
* **VM:** QEMU, `aarch64`, `virt` machine (QEMU 10.0 ARM Virtual Machine, alias `virt-10.0`), `gic-version=3`
* **Guest:** Windows 11 ARM64, installer only (never reaches guest tools install)
* **Windows ISO:** `26100.4349.250607-1500.ge_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.iso` — build 26100.4349, Consumer/Retail, ARM64 (A64FRE), en-us. Obtained via CrystalFetch (UUPdump-based), verified structurally valid (`hdiutil imageinfo` recognizes ISO9660/UDF hybrid; `efi/boot/bootaa64.efi` is a valid signed `PE32+ (EFI application) Aarch64, for MS Windows`, 2,647,480 bytes).

### Issue

A fresh Windows 11 ARM64 VM created for testing the new DirectX/Neptune graphics support hangs indefinitely during boot, every time, regardless of VM configuration. The firmware (EDK2) successfully finds and *loads* the boot entry, then freezes solid the instant it tries to *execute* it. CPU usage stays pegged at ~270-290% (multi-core) indefinitely with zero further guest activity — confirmed via debug log that the guest produces **no further SPICE/display output at all** after the freeze (over 100+ seconds of complete silence in one test, 4+ minutes in another, until force-killed).

### Steps to reproduce

1. Create a QEMU `aarch64` VM: 8192 MB RAM, 6 cores, Hypervisor (HVF) enabled, UEFI boot enabled, TPM 2.0 device enabled (required for Windows 11 setup).
2. Attach the Windows 11 ARM64 ISO above as a boot drive.
3. Attach a blank system disk.
4. Start the VM and let it boot from the ISO.

### Expected result

Firmware boot manager loads and executes the Windows Boot Manager (`bootaa64.efi`), proceeding to the Windows Setup screen.

### Actual result

Boot manager log shows (verbatim, host console):

```
BdsDxe: loading Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-4.1" from PciRoot(0x0)/Pci(0x3,0x0)/USB(0x7,0x0)/USB(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-4.1" from PciRoot(0x0)/Pci(0x3,0x0)/USB(0x7,0x0)/USB(0x0,0x0)
```

...and then the VM freezes on the TianoCore splash screen indefinitely (left running over 11 minutes on the first occurrence). This reproduces identically regardless of which boot-media interface is used (see isolation testing below) — the boot log text simply changes to match whichever boot option is attempted (e.g. `Boot0003 "UEFI Misc Device 2"` for a VirtIO-attached drive), but the hang always occurs immediately after the "starting BootXXXX" line, before any subsequent firmware or bootloader output appears.

### Isolation testing performed

I methodically varied every VM-configuration axis I could think of; **all combinations produce the identical hang** at the same point ("starting BootXXXX", zero output after):

| Variable | Values tested | Result |
| --- | --- | --- |
| Display device | `virtio-gpu-gl-pci` (Neptune: `venus=true,neptune=true`) vs. plain `virtio-gpu-pci` (`gl=off`) | Hangs identically either way — rules out Neptune/GPU backend |
| Boot media interface | `usb-storage` (`media=cdrom`), `virtio-scsi` (`scsi-cd`), fixed non-removable `virtio-blk-pci` (ISO copied in as a plain disk image) | Hangs identically on all three (SCSI/VirtIO variants fail to even reach the same visible frame as long, appearing to freeze faster, but debug-log analysis confirms genuine silence, not progress) |
| CPU acceleration | `-accel hvf` (hardware) vs. `-accel tcg` (pure software emulation) | Hangs identically — rules out HVF/Hypervisor.framework specifically |
| TPM / Secure Boot | `TPMDevice=true` (uses `edk2-aarch64-secure-code.fd`) vs. `TPMDevice=false` (uses non-secure firmware) | Hangs identically — rules out Secure Boot / EFI-vars initialization |

QEMU command line for the last (fixed VirtIO) test, for reference:

```
qemu-system-aarch64 -L .../Library/Caches/qemu -S -spice unix=on,...,gl=off ... -device virtio-gpu-pci ... -cpu host -smp cpus=6,sockets=1,cores=6,threads=1 -machine virt,gic-version=3 -accel hvf -drive if=pflash,format=raw,unit=0,file.filename=.../edk2-aarch64-secure-code.fd,file.locking=off,readonly=on -drive if=pflash,unit=1,file.filename=.../efi_vars.fd -m 8192 ... -device nvme,drive=drive834BDA47-...,bootindex=0 -drive if=none,media=disk,id=drive834BDA47-...,file.filename=.../834BDA47-....qcow2 -device virtio-blk-pci,drive=driveEE1E4F44-...,bootindex=1 -drive if=none,media=disk,id=driveEE1E4F44-...,file.filename=.../26100.4349.250607-1500.ge_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.iso ... -device tpm-crb-device,tpmdev=tpm0
```

### Additional notes

* The `main` branch HEAD is identical to the `v5.0.5` tag (`b6f7475`), so this is not something already fixed post-release.
* I did not find an existing issue matching this exact symptom (searched for boot hangs, `BdsDxe`, HVF freezes, M4-specific reports — found #6944 and #6936 which mention M4/M4 Max-specific behavior, but neither matches this symptom directly).
* Given the consistent freeze point across every backend permutation, I suspect this may be specific to either (a) this exact Windows 11 ARM64 build/bootloader on this UTM/QEMU version, or (b) something host-specific to Apple M4 Max under this beta's HVF/TCG paths — happy to help test further if there's a specific hypothesis you'd like checked (e.g., a different Windows build, a different QEMU `virt` machine version override, etc.).

Reproduce the hang using the reported UTM 5.0.5 QEMU aarch64 virt setup and the final command line; begin with the EDK2 BdsDxe “starting Boot0001” transition and the Windows bootaa64.efi. Done means identifying why execution stops there and confirming a fix reaches Windows Setup across the reported permutations.

Written by the indexing model from the issue text.