semantic: 0.931 network: 0.925 other: 0.924 device: 0.915 instruction: 0.906 boot: 0.902 graphic: 0.902 vnc: 0.900 assembly: 0.881 KVM: 0.877 mistranslation: 0.867 socket: 0.826 QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered that some of my own numerical programs, and also a GNU configure script for at least one package with CC=clang, would cause an instant crash of the VM, sometimes also destroying recently opened files, and producing long strings of NUL characters in /var/log/syslog in the S/390 guest O/S. Further detective work narrowed the cause of the crash down to a single IBM S/390 instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920 workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x. % cat bug-sqrtl-one-line.c int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);} % cc bug-sqrtl-one-line.c && ./a.out Segmentation fault (core dumped) The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable under a debugger. However, I observe that S/390 is the only CPU family that I know of, except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware. Thus, this instruction bug may not have been seen before. Another way to reproduce this bug is with qemu-s390x and a cross-compiled binary: $ s390x-linux-gnu-gcc-5 -static -o bug-sqrtl-one-line.s390x bug-sqrtl-one-line.c $ qemu-s390x bug-sqrtl-one-line.s390x Segmentation fault (core dumped) Find attached the binary. With --enable-debug, qemu-s390x: /home/rth/qemu/qemu/include/tcg/tcg.h:687: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. which turns out to be related to a null-pointer temporary. I confirm that the patch https://lists.gnu.org/archive/html/qemu-s390x/2020-06/msg00213.html fixes the issue, both for qemu-s390x and qemu-system-s390x. Thanks Richard! This bug was fixed in the package qemu - 1:5.0-5ubuntu4 --------------- qemu (1:5.0-5ubuntu4) groovy; urgency=medium * xen: provide compat links to what libxen-dev reports where to find the binaries (LP: #1890005) * d/p/ubuntu/lp-1883984-target-s390x-Fix-SQXBR.patch: avoid crash on SQXBR (LP: #1883984) * d/p/lp-1890154-*: fix -no-reboot on s390x secure boot (LP: #1890154) -- Christian Ehrhardt