summary refs log tree commit diff stats
path: root/results/scraper/gitlab/issues_text/target_arm/host_missing/accel_HVF/1073
blob: 08ddc332c303b9998c8f54fe9b8fdc3f96f6e8c4 (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
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: