diff options
Diffstat (limited to 'gitlab/issues_text/target_i386/host_arm/accel_TCG')
5 files changed, 197 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659 new file mode 100644 index 000000000..e182cc15d --- /dev/null +++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/1659 @@ -0,0 +1,27 @@ +x86 vm fails to stop on Darwin aarch64 when qemu compiled with -O1/-O2 +Description of problem: +When compiled with `-O2` or `-O1` qemu process hangs on full VM stopping on macOS aarch64 host if `shutdown -P now` initiated from guest system. +Steps to reproduce: +1. Compile latest qemu version with -O2 (default value) or -O1 passed +2. Run qemu-system-x86_64 with ubuntu image, e.g. https://cloud-images.ubuntu.com/focal/20230215/focal-server-cloudimg-amd64.img and custom cloud-init (for user/password authentication) +3. Wait until image is loaded, connect via vnc or provide login/password in stdio +4. Initiate shutdown with `sudo shutdown -P now` +5. See that VM indefinitely shutdowns +6. Kill VM from host system with kill -9 <qemu-system-x86_64-process-pid> +7. Recompile qemu with -O0 +8. Repeat steps 2-4 +9. See that vm successfully stopped, and qemu process exited with code 0 +Additional information: +I've created thread dump from activity monitor with threads which qemu hanging on, attached below +[sample-qemu-system-x86_64.txt](/uploads/119b89b7f55f4374acb9ae1f9dc2e517/sample-qemu-system-x86_64.txt) + +Probably there is some compiler optimisation which prevents qemu threads from receive shutdown signal or appropriate notification from another threads. + +The compiler version with which qemu is built: +```bash +% cc --version +Apple clang version 14.0.3 (clang-1403.0.22.14.1) +Target: arm64-apple-darwin22.4.0 +Thread model: posix +InstalledDir: /Library/Developer/CommandLineTools/usr/bin +``` diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101 new file mode 100644 index 000000000..e92dfe930 --- /dev/null +++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2101 @@ -0,0 +1,17 @@ +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168 new file mode 100644 index 000000000..cd2af620a --- /dev/null +++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2168 @@ -0,0 +1,32 @@ +qemu-x86_64: segfault when running grep on arm64 host +Description of problem: +An internal segmentation fault occurs when attempting to run `grep` in a Gentoo stage3 chroot +Steps to reproduce: +1. Unpack an x86_64 chroot environment (easiest way is using one of Gentoo's stage3s from https://get.gentoo.org) +2. Run `qemu-x86_64 -L /path/to/x86_64/chroot /path/to/x86_64/chroot/bin/grep` +Additional information: +It seems this only occurs in 8.x.x, 7.x.x does not have this segfault. + +Output: +``` +# qemu-x86_64 -L /bugs/grep-sandbox /bugs/grep-sandbox/bin/grep +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +``` + +GDB bt: +``` +(gdb) bt +#0 open_self_maps_2 (opaque=0xffffffffd0b0, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000000000048539c in walk_memory_regions (priv=priv@entry=0xffffffffd0b0, fn=fn@entry=0x4a13e4 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x00000000004a20bc in open_self_maps_1 (smaps=false, fd=3, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x00000000004aaa00 in do_guest_openat (cpu_env=cpu_env@entry=0x862050, dirfd=dirfd@entry=-100, fname=fname@entry=0x5555555776f1 "/proc/self/maps", flags=0, mode=mode@entry=0, safe=safe@entry=true) + at ../linux-user/syscall.c:8381 +#5 0x00000000004b0cc4 in do_syscall1 (cpu_env=cpu_env@entry=0x862050, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=93824992376561, arg3=arg3@entry=0, arg4=arg4@entry=0, + arg5=arg5@entry=93824992373306, arg6=arg6@entry=0, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x00000000004b2770 in do_syscall (cpu_env=cpu_env@entry=0x862050, num=257, arg1=4294967196, arg2=93824992376561, arg3=0, arg4=0, arg5=93824992373306, arg6=0, arg7=arg7@entry=0, arg8=arg8@entry=0) + at ../linux-user/syscall.c:13658 +#7 0x0000000000404fdc in cpu_loop (env=env@entry=0x862050) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x0000000000400d7c in main (argc=4, argv=0xffffffffed48, envp=<optimized out>) at ../linux-user/main.c:1014 +``` diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271 new file mode 100644 index 000000000..d192cea1d --- /dev/null +++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2271 @@ -0,0 +1,16 @@ +pci passthrough fails from aarch64 to amd64 guest +Description of problem: +**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below** + +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument) + +pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64). + +AMD64 guest VM otherwise works correctly if -device vfio-pci is not used. + +libvirt / virtmanager fail for aarch64 host -> amd64 guest as well. +Steps to reproduce: +1. Unbind pass-thru device from host. +2. Attach pass-thru device to vfio-pci +3. Execute qemu-system-amd64 as above. diff --git a/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560 b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560 new file mode 100644 index 000000000..bf6bca7fd --- /dev/null +++ b/gitlab/issues_text/target_i386/host_arm/accel_TCG/2560 @@ -0,0 +1,105 @@ +Go garbage collector crashes when using qemu-x86_64 on an aarch64 host +Description of problem: +Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something? + +The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`. + +Output from Go when it crashes: + +``` +$ sudo chroot . go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0xa95b29?, 0x797b1e2a383c?}) + runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c +runtime.(*lfstack).push(0x0?, 0xc0005041c0?) + runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45 +runtime.(*spanSetBlockAlloc).free(...) + runtime/mspanset.go:322 +runtime.(*spanSet).reset(0xf46980) + runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219 +runtime.finishsweep_m() + runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd +runtime.gcStart.func2() + runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f +runtime.systemstack(0x0) + runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a +```` +Steps to reproduce: +0. Use an aarch64 host system! + +1. Set up binfmt to use qemu-x86_64: + +``` +$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 +enabled +interpreter /usr/bin/qemu-x86_64 +flags: OCF +offset 0 +magic 7f454c4602010100000000000000000002003e00 +mask fffffffffffefe00fffffffffffffffffeffffff +``` + +2. Download/extract x86_64 rootfs: + +``` +$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz +``` + +3. Create example app in the x86_64 rootfs: + +``` +package main + +func main() { +} +``` + +4. Build using chroot: + +``` +$ sudo chroot /path/to/x86_64/rootfs apk add go +$ sudo chroot /path/to/x86_64/rootfs go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push +... +``` + +5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU: + +``` +$ sudo chroot . env GOGC=off go build main.go +# might have to mount /dev to build successfully, but Go doesn't panic! +``` +Additional information: +I've bisected this exact crash/failure to: + +``` +commit 2952b642a555207748dd961fcbfdc48f198eebb6 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Feb 13 10:20:27 2024 -1000 + + linux-user: Split out do_munmap + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +Though a different crash starts happening at the commit before that one: + +``` +commit ad87d26e6bb13257409f412224c862fc54025e8b +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jan 2 12:57:55 2024 +1100 + + linux-user: Do early mmap placement only for reserved_va + + For reserved_va, place all non-fixed maps then proceed + as for MAP_FIXED. + + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +FYI @rth7680 |