** No longer affects: qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920784
Title:
qemu-system-ppc64le fails with kvm acceleration
Status in The Ubuntu-power-systems project:
In Progress
St
** Also affects: glibc (Ubuntu Hirsute)
Importance: Undecided
Status: Invalid
** Also affects: qemu (Ubuntu Hirsute)
Importance: Undecided
Status: Invalid
** Also affects: linux (Ubuntu Hirsute)
Importance: Undecided
Assignee: Frank Heimes (fheimes)
Status: In P
The fix was sent to the kernel teams mailing list:
https://lists.ubuntu.com/archives/kernel-team/2021-March/thread.html#118449
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Changed in: ubuntu-power-systems
Status: Confirmed => In Progress
--
You received this b
@Sadoon - yes, that is the same fix that Laurent pointed to a few hours
before.
@Frank - the kernel I had before was 5.11.0-11-generic (failing). I've
tested "5.11.0-13-generic #14~lp1920784" from your PPA and can confirm
that this fixes the issue.
Thanks Laurent for identifying the fix and thank
And gladly this was only added in >=5.9 and we have Groovy (5.8) and
Hirsute (5.11) so only the Hirsute kernel is needed to adapt, but
further backports are not needed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
The guys on the Fedora side seem to have found the patch to fix this:
https://bugzilla.redhat.com/show_bug.cgi?id=1941652#c6
Apparently it will go upstream in Linux 5.11, but earlier versions also
need the fix, specifically 5.9 and 5.10
Thank you!
** Bug watch added: Red Hat Bugzilla #1941652
Thx Laurent, I took the hirsute master-next source and cherry-picked the patch
and it applied cleanly.
Now I kicked off a kernel build of this patched kernel in the following PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1920784
(however, the builds will take some time to complete)
If it
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920784
Title:
qemu-system-ppc64le fails with kvm acceleration
Status in Q
You need a kernel with a the following fix for POWER9:
commit 25edcc50d76c834479d11fcc7de46f3da4d95121
Author: Fabiano Rosas
Date: Thu Feb 4 17:05:17 2021 -0300
KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path
The Facility Status and Control Register is a privileged SPR t
I might be spoiled by the s390x-POP style to define instructions, but in
the following doc about the PowerISA unfortunately there is no list of
reasons-for-SIGILL. Therefore I'm out of options on this waiting for
someone - most likely IBM - to chime in.
https://wiki.raptorcs.com/w/images/f/f5/Powe
As my other repro-code didn't trigger the issue I looked at qemu again
and found that before the failing ioctl->scv call there are plenty other
even some very similar (same?) calls that work just fine.
I wonder if on guest setup qemu (or e.g. the rom we load) might set some
arch-bits or such which
** Also affects: ubuntu-power-systems
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920784
Title:
qemu-system-ppc64le fails with kvm acceleration
Statu
qemu calls this ioctl on ppc64 as:
sysdeps/unix/sysv/linux/powerpc/ioctl.c
result = INLINE_SYSCALL (ioctl, 3, fd, request, arg);
The mapping of macros in sysdeps/unix/sysv/linux/powerpc/sysdep.h seems to be:
INTERNAL_SYSCALL -> INTERNAL_SYSCALL_NCS -> TRY_SYSCALL_SCV -> SYSCALL_SCV
76 #define
[10] outlined to use PPC_FEATURE2_SCV but [4] does just that.
In addition [6] added power9 machine settings as only on this ISA it
is available - like:
+ .machine "push"
+ .machine "power9"
scv 0
+ .machine "pop"
Maybe there is some generated "scv 0" left that needs t
Since this seems to be broken on all Distributions as soon as the triggering
combination of kernel/glibc is present I think we'd want to open that up to
upstream qemu for a wider discussion and to also hit the ppc64 architecture
experts.
Furthermore I'm not entirely sure if this needs to be fixed
Hi Sadoon,
thanks for the report!
There isn't much to find about this issue yet.
One automatic syscaller crash report [1].
On the emulation side there is [2][3].
On the glibc side we have [4][5] adding the use of it with [6] being a fix.
All those seem to be in glibc 2.33 - so I'd expect with [6]
16 matches
Mail list logo