Description of problem: (Suspected glibc issue!) qemu-system-ppc64 fails when invoked with kvm acceleration with error "illegal instruction" > qemu-system-ppc64 -M pseries,accel=kvm Illegal instruction (core dumped) In dmesg: Facility 'SCV' unavailable (12), exception at 0x7624f8134c0c, MSR=900000000280f033 Version-Release number of selected component (if applicable): 5.2.0 (qemu-5.2.0-5.fc34.1) Linux kernel 5.11 (5.11.3-300.fc34.ppc64le) glibc 2.33 (2.33-5.fc34) How reproducible: Always Steps to Reproduce: 1. Run qemu with kvm acceleration Actual results: Illegal instruction Expected results: Normal VM execution Additional info: The machine is a Raptor Talos II Lite with a Sforza V1 8-core, but was also observed on a Raptor Blackbird with the same processor. This was also observed on Ubuntu 21.04 testing, which uses glibc 2.33 Also tested on ArchPOWER (unofficial port of Arch Linux for ppc64le) with glibc 2.33 Fedora 33 and Ubuntu 20.10, both using glibc 2.32 do not have this issue, and downgrading the Linux kernel from 5.11 to 5.4 LTS on ArchPOWER solved the problem. Kernel 5.9 and 5.10 have the same issue when combined with glibc2.33
David - any idea about this one?
I think you need: 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path")
Created attachment 1765332 [details] Core dump
The problem happens because glibc uses the new SCV call rather than SC and this needs a kernel support. This needs kernel support, but included in 5.9 commit 7fa95f9adaee7e5cbb195d3359741120829e488b Author: Nicholas Piggin <npiggin> Date: Thu Jun 11 18:12:03 2020 +1000 powerpc/64s: system call support for scv/rfscv instructions Add support for the scv instruction on POWER9 and later CPUs. For now this implements the zeroth scv vector 'scv 0', as identical to 'sc' system calls, with the exception that LR is not preserved, nor are volatile CR registers, and error is not indicated with CR0[SO], but by returning a negative errno. rfscv is implemented to return from scv type system calls. It can not be used to return from sc system calls because those are defined to preserve LR. getpid syscall throughput on POWER9 is improved by 26% (428 to 318 cycles), largely due to reducing mtmsr and mtspr. Signed-off-by: Nicholas Piggin <npiggin> [mpe: Fix ppc64e build] Signed-off-by: Michael Ellerman <mpe.au> Link: https://lore.kernel.org/r/20200611081203.995112-3-npiggin@gmail.com For POWER9, we need also this bugfix: 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path")
Moving to "kernel" component per comment 4.
(In reply to Laurent Vivier from comment #4) > The problem happens because glibc uses the new SCV call rather than SC and > this needs a kernel support. > > This needs kernel support, but included in 5.9 > > commit 7fa95f9adaee7e5cbb195d3359741120829e488b > Author: Nicholas Piggin <npiggin> > Date: Thu Jun 11 18:12:03 2020 +1000 > > powerpc/64s: system call support for scv/rfscv instructions > > Add support for the scv instruction on POWER9 and later CPUs. > > For now this implements the zeroth scv vector 'scv 0', as identical to > 'sc' system calls, with the exception that LR is not preserved, nor > are volatile CR registers, and error is not indicated with CR0[SO], > but by returning a negative errno. > > rfscv is implemented to return from scv type system calls. It can not > be used to return from sc system calls because those are defined to > preserve LR. > > getpid syscall throughput on POWER9 is improved by 26% (428 to 318 > cycles), largely due to reducing mtmsr and mtspr. > > Signed-off-by: Nicholas Piggin <npiggin> > [mpe: Fix ppc64e build] > Signed-off-by: Michael Ellerman <mpe.au> > Link: https://lore.kernel.org/r/20200611081203.995112-3-npiggin@gmail.com > > For POWER9, we need also this bugfix: > > 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path") Can confirm that this patch works in ArchPOWER with linux 5.11.7, thank you! I am not familiar with the build system of Fedora, otherwise I would have tested there too.
Right, this looks like a Fedora dupe of the RHEL9 bug 1922974.
I'm closing this bug as the fix is upstream so it will eventually make its way through to Fedora.
I would prefer to include the mentioned commit in Fedora 5.11 kernels, there is long time before F-34 will be on 5.12
should be in the next 5.11 build via https://gitlab.com/cki-project/kernel-ark/-/commit/d6e1043c3ee761b14ddae1707e78f10b26868c19
Does this bug have to be private? Thanks.
Remove private group.