kernel: 0.913
device: 0.909
peripherals: 0.836
graphic: 0.802
performance: 0.786
architecture: 0.783
virtual: 0.670
vnc: 0.656
network: 0.644
hypervisor: 0.625
debug: 0.613
arm: 0.604
boot: 0.596
ppc: 0.544
PID: 0.515
socket: 0.513
files: 0.512
permissions: 0.509
register: 0.452
TCG: 0.445
user-level: 0.428
risc-v: 0.423
semantic: 0.412
mistranslation: 0.377
VMM: 0.374
assembly: 0.236
x86: 0.164
i386: 0.155
KVM: 0.142

SIGABRT with -M raspi3b,accel=hvf on macOS
Description of problem:
There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort:
```
(lldb) bt
* thread #3, stop reason = signal SIGUSR2
  * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8
    frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9
    frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14
    frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25
```

I tried skipping over it with `lldb`:
```
(lldb) b main
(lldb) r
(lldb) process handle SIGUSR1 -s false -p true
(lldb) process handle SIGUSR2 -s false -p true
(lldb) c
qemu-system-aarch64: Unknown Error
```

I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail.
Steps to reproduce:
1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G`
2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio
`
Additional information: