QEMU LoongArch regression after merging LASX changes

Host environment

  • Operating system: Debian Linux Bookworm
  • OS/kernel version: 6.2.16-12-pve
  • Architecture: x86_64
  • QEMU flavor: qemu-system-loongarch64
  • QEMU version: v8.1.0-1000-g494a6a2c
  • QEMU command line: 
    ./qemu-system-loongarch64 \
     -m 64G \
     -cpu la464-loongarch-cpu \
     -machine virt \
     -smp 16 \
     -bios ./QEMU_EFI_7.2.fd \
     -nographic \
     -device virtio-net,netdev=net0 \
     -netdev user,id=net0,hostfwd=tcp::4444-:22 \
     -hda gentoo.qcow2

Emulated/Virtualized environment

  • Operating system: Gentoo Linux
  • OS/kernel version: Linux 6.5
  • Architecture: LoongArch

Description of problem

After enabling LASX in qemu (@gaosong), booting Gentoo Linux with latest glibc master (w/ LSX & LASX optimized libc routines) will fail in systemd:

[   10.350207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000085
[   10.350557] CPU: 5 PID: 1 Comm: systemd Not tainted 6.5.2-gentoo #2
[   10.350655] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[   10.350961] Stack : 0072617764726148 0000000000000000 9000000000223440 90000001000e4000
[   10.351181]         90000001000e7990 90000001000e7998 0000000000000000 90000001000e7ad8
[   10.351294]         90000001000e7ad0 90000001000e7ad0 90000001000e7900 0000000000000001
[   10.351406]         0000000000000001 90000001000e7998 ec94a2e1446052e6 9000000100438140
[   10.351519]         0000000000000001 0000000000000003 0000000000000000 0000000000000030
[   10.351630]         0000000000000000 00000000000559bf 00000000056e0000 0000000000000004
[   10.351745]         0000000000000000 0000000000000000 900000000162b438 900000000177e000
[   10.351856]         00000000400004d8 0000000000000001 0000000000000018 90000001000e7c84
[   10.351968]         0000000000020000 0000000000000000 9000000000223458 00007ffff0341af0
[   10.352081]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
[   10.352196]         ...
[   10.352277] Call Trace:
[   10.352482] [<9000000000223458>] show_stack+0x5c/0x180
[   10.353518] [<9000000001178d4c>] dump_stack_lvl+0x60/0x88
[   10.353592] [<900000000115cd7c>] panic+0x13c/0x308
[   10.353670] [<900000000024244c>] do_exit+0x860/0x868
[   10.353735] [<900000000024261c>] do_group_exit+0x34/0x94
[   10.353803] [<9000000000250514>] get_signal+0x75c/0x804
[   10.353869] [<90000000002254c4>] arch_do_signal_or_restart+0x74/0xae0
[   10.353944] [<90000000002c738c>] exit_to_user_mode_loop.isra.0+0x90/0x10c
[   10.354041] [<9000000001179ff0>] irqentry_exit_to_user_mode+0x1c/0x28
[   10.354119] [<90000000011792f8>] do_bp+0xcc/0x2ac
[   10.354222] [<90000001005a1924>] 0x90000001005a1924
[   10.354522] [<00007ffff0341af0>] 0x7ffff0341af0

Full log:

stderr

Instruction trace -d in_asm,out_asm,op (very large):

log.tar.zstd

I also tried to boot LoongArchLinux whose glibc does not have LSX/LASX optimized C routines, and it can boot without problems. If I chroot from LoongArchLinux into Gentoo Linux, running emerge command will SIGSEGV.

If I disable LASX in CPUCFG2, the problem is gone:

//     data = FIELD_DP32(data, CPUCFG2, LASX, 1),

I guess the bug is related to LASX assemblies in glibc.

Steps to reproduce

  1. Launch qemu
  2. Wait for systemd to be killed
  3. Collect logs

Additional information