On Tue, May 26, 2026 at 7:20 AM Ilya Leoshkevich <[email protected]> wrote: > > On 5/25/26 17:22, Matt Turner wrote: > > QEMU keeps the s390x floating-point control register (FPC) in env->fpc. > > The rounding mode bits [2:0] of FPC are reflected into the derived > > env->fpu_status via set_float_rounding_mode(); every architectural > > write to FPC goes through HELPER(sfpc) which keeps the two in sync. > > > > restore_sigregs() restored FPC with a direct assignment: > > > > __get_user(env->fpc, &sc->fpregs.fpc); > > > > This wrote env->fpc correctly but never updated env->fpu_status, so on > > sigreturn the interrupted code resumed with whatever rounding mode the > > signal handler last installed in fpu_status. > > > > Factor the two-step "write fpc + sync fpu_status" logic out of > > HELPER(sfpc) into cpu_s390x_load_fpc(), declare it in cpu.h, and call > > it from restore_sigregs() in place of the direct assignment. > > cpu_s390x_load_fpc() omits the specification-exception check that > > HELPER(sfpc) performs; raw signal frame restoration does not validate > > the saved state. > > > > Fixes: 2941e0fa05 ("linux-user/s390x: Save/restore fpc when handling a > > signal") > > Cc: [email protected] > > --- > > linux-user/s390x/signal.c | 6 +++++- > > target/s390x/cpu.h | 1 + > > target/s390x/tcg/fpu_helper.c | 6 ++++++ > > 3 files changed, 12 insertions(+), 1 deletion(-) > > Just curious, how did you stumble upon this? > It looks like a source of nasty intermittent bugs.
Indeed. I spent a lot of time this weekend debugging the `signals` test on sh4, which resulted in this patch: https://lists.gnu.org/archive/html/qemu-devel/2026-05/msg06646.html It was hard to debug from scratch, but the solution was so simple and the problem so obvious (if you know to look for it) that I figured I would do an audit of other architectures. I found this, as well as an issue on MIPS and another on PPC. Hopefully my ten minutes of effort on s390/mips/ppc will save someone a couple of days in the future. :)
