blob: ce322bc06b0d5b4f5a6ebe699515496d27ae102d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
id = 1147
title = "x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu)"
state = "closed"
created_at = "2022-08-07T20:06:19.889Z"
closed_at = "2023-01-17T15:47:24.283Z"
labels = ["Closed::Fixed", "accel: TCG", "host: arm"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/1147"
host-os = "Asahi Linux"
host-arch = "aarch64"
qemu-version = "7.0.0"
guest-os = "Ubuntu 22.04 LTS"
guest-arch = "x86_64"
description = """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)."""
reproduce = "n/a"
additional = "n/a"
|