summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2/output/hypervisor/1073
blob: c5dae0a9cc87932984cf40d80107bb799b4592ec (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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: