On 8/8/2025 3:17 AM, Cédric Le Goater wrote:
On 8/8/25 08:07, Michael Tokarev wrote:
On 06.08.2025 23:46, Miles Glenn wrote:
On Tue, 2025-08-05 at 22:07 +0200, Cédric Le Goater wrote:
...
These seem to be interesting to have :
ppc/xive2: Fix treatment of PIPR in CPPR update
ppc/xive2: Fix irq preempted by lower priority group irq
I added :
ppc/xive2: Reset Generation Flipped bit on END Cache Watch
ppc/xive: Fix PHYS NSR ring matching
ppc/xive2: fix context push calculation of IPB priority
ppc/xive2: Remote VSDs need to match on forwarding address
ppc/xive2: Fix calculation of END queue sizes
ppc/xive: Report access size in XIVE TM operation error logs
ppc/xive: Fix xive trace event output
I'm still not sure that the benefit is worth the effort, but I
certainly don't have a problem with them being backported if someone
has the desire and the time to do it.
I mentioned already that 10.0 series will (hopefully) be LTS series.
At the very least, it is what we'll have in the upcoming debian
stable release (trixie), which will be stable for the next 2 years.
Whenever this is important to have working Power* support in debian -
I don't know.
All the mentioned patches applied to 10.0 branch cleanly (in the
reverse order, from bottom to top), so there's no effort needed
to back-port them. And the result passes at least the standard
qemu testsuite. So it looks like everything works as intended.
24.04 operates correctly with a "6.14.0-27-generic #27~24.04.1-Ubuntu"
kernel on a PowerNV10 system defined as :
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Model name: POWER10, altivec supported
Model: 2.0 (pvr 0080 1200)
Thread(s) per core: 4
Core(s) per socket: 2
Socket(s): 2
Frequency boost: enabled
CPU(s) scaling MHz: 76%
CPU max MHz: 3800.0000
CPU min MHz: 2000.0000
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
NUMA:
NUMA node(s): 2
NUMA node0 CPU(s): 0-7
NUMA node1 CPU(s): 8-15
with devices :
0000:00:00.0 PCI bridge: IBM Device 0652
0000:01:00.0 Non-Volatile memory controller: Red Hat, Inc. QEMU NVM
Express Controller (rev 02)
0001:00:00.0 PCI bridge: IBM Device 0652
0001:01:00.0 PCI bridge: Red Hat, Inc. Device 000e
0001:02:02.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
Controller (rev 03)
0001:02:03.0 Ethernet controller: Intel Corporation 82574L Gigabit
Network Connection
0002:00:00.0 PCI bridge: IBM Device 0652
...
A rhel9 nested guest boots too.
Poweroff and reboot are fine.
Michael,
I would say ship it.
Glenn, Gautam,
It would nice to get rid of these messages.
[ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[ 2.270794918,5] XIVE: [ IC 00 ] Resetting one xive...
[ 2.271575295,3] XIVE: [CPU 0000] Error enabling PHYS CAM already
enabled
CPU 0100 Backtrace:
S: 0000000032413a20 R: 0000000030021408 .backtrace+0x40
S: 0000000032413ad0 R: 000000003008427c .xive2_tima_enable_phys+0x40
S: 0000000032413b50 R: 0000000030087430
.__xive_reset.constprop.0.isra.0+0x520
S: 0000000032413c90 R: 0000000030087638 .opal_xive_reset+0x78
S: 0000000032413d10 R: 00000000300038bc opal_entry+0x14c
--- OPAL call token: 0x80 caller R1: 0xc0000000014bbc90 ---
[ 2.273581201,3] XIVE: [CPU 0001] Error enabling PHYS CAM already
enabled
Is it a modeling issue ?
I do not think it a modeling issue We do get any warning or error
messages when booting Linux on Power VM. Note that " [PATCH 43/50]
ppc/xive: Check TIMA operations validity" added some warning logs. The
problem is that the Context is 'hardware owned' since it is already
pushed/enabled.
MAK
Thanks,
C.
