blob: 10895280931fa45eb460a6a86f769c681f06eeb6 (
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
x86: 0.933
graphic: 0.900
TCG: 0.840
architecture: 0.777
kernel: 0.703
device: 0.693
semantic: 0.499
performance: 0.412
vnc: 0.406
ppc: 0.406
arm: 0.332
risc-v: 0.299
user-level: 0.282
PID: 0.280
register: 0.277
socket: 0.259
files: 0.242
mistranslation: 0.234
permissions: 0.232
boot: 0.189
debug: 0.165
VMM: 0.144
virtual: 0.097
network: 0.074
peripherals: 0.073
assembly: 0.069
hypervisor: 0.057
i386: 0.020
KVM: 0.003
--------------------
x86: 0.986
kernel: 0.889
TCG: 0.448
hypervisor: 0.176
debug: 0.109
virtual: 0.027
files: 0.026
user-level: 0.018
architecture: 0.016
register: 0.016
performance: 0.015
PID: 0.015
device: 0.011
arm: 0.006
VMM: 0.006
boot: 0.005
KVM: 0.004
assembly: 0.002
semantic: 0.002
socket: 0.002
network: 0.002
ppc: 0.001
peripherals: 0.001
graphic: 0.001
permissions: 0.001
vnc: 0.000
risc-v: 0.000
mistranslation: 0.000
i386: 0.000
x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu)
Description of problem:
Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.`
No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above.
Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi.
These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit).
|