hvf_vcpu_exec isv assert with qemu-xhci device
Description of problem:
Using the qemu-xhci device with HVF on darwin-aarch64 causes [this assert](https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/hvf/hvf.c#L1920) to fire.

```
travis@gmachine vms % cat launch.sh
#!/usr/bin/env bash

~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 \
    -nographic \
    -machine virt \
    -accel hvf \
    -cpu host \
    -m 16M \
    -device qemu-xhci \
    -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
travis@gmachine vms % ./launch.sh


U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)

DRAM:  16 MiB (effective 16 EiB)
Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1920.
./launch.sh: line 10: 22295 Abort trap: 6           ~/sources/nixpkgs/result-qemu/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios ~/sources/nixpkgs/result-uboot-bin/u-boot.bin
```

This is NixOS' build of u-boot 2024.04. This is also Nixpkgs' build of qemu-9.0.0; by default it contains some patches, but if I remove those and build with the unmodified release tarball there's no change in behavior. Naturally this doesn't happen with TCG and I haven't found any other (non-USB) device to cause this issue.
Steps to reproduce:
On a darwin-aarch64 machine with git and nix setup (8.2.2 is latest in Nixpkgs head, the same problem occurs with 9.0.0):

```
% git clone https://github.com/nixos/nixpkgs
% cd ./nixpkgs
% $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel hvf -cpu host -m 16M -device qemu-xhci -bios $(nix-build -E 'with import ./default.nix {system = "aarch64-linux";}; ubootQemuAarch64')/u-boot.bin


U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)

DRAM:  16 MiB (effective 16 EiB)
Assertion failed: (isv), function hvf_vcpu_exec, file ../target/arm/hvf/hvf.c, line 1915.
zsh: abort      $(nix-build -A qemu)/bin/qemu-system-aarch64 -nographic -machine virt -accel 
```
Additional information:
I have not yet tried other u-boot binaries. I suppose it could be u-boots fault? Eyeballing hvf.c this seems to be an unhandled case in the MMIO callback? I'm far out of my element so that could be total nonsense.