docs/system/ppc/powernv.rst | 9 +- hw/ppc/pnv.c | 540 +++++++++++++++++++++++++ hw/ppc/pnv_chiptod.c | 59 +++ hw/ppc/pnv_core.c | 17 + include/hw/ppc/pnv.h | 38 ++ include/hw/ppc/pnv_chip.h | 7 + include/hw/ppc/pnv_chiptod.h | 2 + include/hw/ppc/pnv_xscom.h | 49 +++ tests/functional/test_ppc64_powernv.py | 34 +- 9 files changed, 737 insertions(+), 18 deletions(-)
Overview
============
Add support for Power11 powernv machine type.
As Power11 core is same as Power10, hence much of the code has been reused
from Power10.
Split Powernv11 chip/machine code into commits introducing: chip,machine,xive,phb
This is to try to keep the code smaller in each commit, but can squash the
xive/phb commits into respective chip/machine commit
Power11 PSeries already added in QEMU in:
commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type")
Git Tree for Testing
====================
QEMU: https://github.com/adi-g15-ibm/qemu/tree/p11-powernv-v9
Has been tested with following cases:
* '-M powernv' / '-M powernv10' / '-M powernv11'
* '-smp' option tested
skiboot with Power11 support: https://github.com/open-power/skiboot, since
commit 785a5e3
Linux with Power11 support: https://github.com/torvalds/linux, since v6.9-rc1
Changelog
=========
v9:
+ [PATCH 1/7]: apply hunks from commit cf0eb929e59cb, and commit
24c8fa968a6d8, for changes that were done for Power10, as those changes
make sense for Power11 also
+ [PATCH 3/7]: fixed build breakage identified with QEMU CI, due to changes
in upstream function pointer types
v8:
+ rebase to upstream
+ propose myself as a powernv reviewer
v7 (https://lore.kernel.org/qemu-devel/20250327200738.1524401-1-adityag@linux.ibm.com/):
+ use Power10 models of homer, sbe, occ, psi, lpc. As they are same.
+ switch powernv tests to use buildroot images instead of op-build images
+ add functional test for powernv11
- remove dynamic sysbus device for PHBs, so no more dynamic number of
PHBs in Power11 as it became complex to handle it and not much used
v6 (https://lore.kernel.org/qemu-devel/20250325112319.927190-1-adityag@linux.ibm.com/):
+ make Pnv11Chip's parent as PnvChip, instead of Pnv10Chip
+ rebase on upstream/master
v5 (https://lore.kernel.org/qemu-devel/57ce8d50-db92-44f0-96a9-e1297eea949f@kaod.org/):
+ add chiptod
+ add instance_init for P11 to use P11 models
+ move patch introducing Pnv11Chip to the last
+ update skiboot.lid to skiboot's upstream/master
v4:
+ patch #5: fix memory leak in pnv_chip_power10_quad_realize
- no change in other patches
v3:
+ patch #1: version power11 as power11_v2.0
+ patch #2: split target hw/pseries code into patch #2
+ patch #3,#4: fix regression due to Power10 and Power11 having same PCR
+ patch #5: create pnv_chip_power11_dt_populate and split pnv_chip_power10_common_realize as per review
+ patch #6-#11: no change
- remove commit to make Power11 as default
v2:
+ split powernv patch into homer,lpc,occ,psi,sbe
+ reduce code duplication by reusing power10 code
+ make power11 as default
+ rebase on qemu upstream/master
+ add more information in commit descriptions
+ update docs
+ update skiboot.lid
Aditya Gupta (7):
ppc/pnv: Introduce Pnv11Chip
ppc/pnv: Introduce Power11 PowerNV machine
ppc/pnv: Add XIVE2 controller to Power11
ppc/pnv: Add PHB5 PCIe Host bridge to Power11
ppc/pnv: Add ChipTOD model for Power11
tests/powernv: Switch to buildroot images instead of op-build
tests/powernv: Add PowerNV test for Power11
docs/system/ppc/powernv.rst | 9 +-
hw/ppc/pnv.c | 540 +++++++++++++++++++++++++
hw/ppc/pnv_chiptod.c | 59 +++
hw/ppc/pnv_core.c | 17 +
include/hw/ppc/pnv.h | 38 ++
include/hw/ppc/pnv_chip.h | 7 +
include/hw/ppc/pnv_chiptod.h | 2 +
include/hw/ppc/pnv_xscom.h | 49 +++
tests/functional/test_ppc64_powernv.py | 34 +-
9 files changed, 737 insertions(+), 18 deletions(-)
--
2.50.1
On 8/8/25 13:59, Aditya Gupta wrote:
> Overview
> ============
>
> Add support for Power11 powernv machine type.
>
> As Power11 core is same as Power10, hence much of the code has been reused
> from Power10.
>
> Split Powernv11 chip/machine code into commits introducing: chip,machine,xive,phb
> This is to try to keep the code smaller in each commit, but can squash the
> xive/phb commits into respective chip/machine commit
>
> Power11 PSeries already added in QEMU in:
> commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type")
>
> Git Tree for Testing
> ====================
>
> QEMU: https://github.com/adi-g15-ibm/qemu/tree/p11-powernv-v9
>
> Has been tested with following cases:
> * '-M powernv' / '-M powernv10' / '-M powernv11'
> * '-smp' option tested
>
> skiboot with Power11 support: https://github.com/open-power/skiboot, since
> commit 785a5e3
>
> Linux with Power11 support: https://github.com/torvalds/linux, since v6.9-rc1
>
> Changelog
> =========
> v9:
> + [PATCH 1/7]: apply hunks from commit cf0eb929e59cb, and commit
> 24c8fa968a6d8, for changes that were done for Power10, as those changes
> make sense for Power11 also
> + [PATCH 3/7]: fixed build breakage identified with QEMU CI, due to changes
> in upstream function pointer types
>
> v8:
> + rebase to upstream
> + propose myself as a powernv reviewer
>
> v7 (https://lore.kernel.org/qemu-devel/20250327200738.1524401-1-adityag@linux.ibm.com/):
> + use Power10 models of homer, sbe, occ, psi, lpc. As they are same.
> + switch powernv tests to use buildroot images instead of op-build images
> + add functional test for powernv11
> - remove dynamic sysbus device for PHBs, so no more dynamic number of
> PHBs in Power11 as it became complex to handle it and not much used
>
> v6 (https://lore.kernel.org/qemu-devel/20250325112319.927190-1-adityag@linux.ibm.com/):
> + make Pnv11Chip's parent as PnvChip, instead of Pnv10Chip
> + rebase on upstream/master
>
> v5 (https://lore.kernel.org/qemu-devel/57ce8d50-db92-44f0-96a9-e1297eea949f@kaod.org/):
> + add chiptod
> + add instance_init for P11 to use P11 models
> + move patch introducing Pnv11Chip to the last
> + update skiboot.lid to skiboot's upstream/master
>
> v4:
> + patch #5: fix memory leak in pnv_chip_power10_quad_realize
> - no change in other patches
>
> v3:
> + patch #1: version power11 as power11_v2.0
> + patch #2: split target hw/pseries code into patch #2
> + patch #3,#4: fix regression due to Power10 and Power11 having same PCR
> + patch #5: create pnv_chip_power11_dt_populate and split pnv_chip_power10_common_realize as per review
> + patch #6-#11: no change
> - remove commit to make Power11 as default
>
> v2:
> + split powernv patch into homer,lpc,occ,psi,sbe
> + reduce code duplication by reusing power10 code
> + make power11 as default
> + rebase on qemu upstream/master
> + add more information in commit descriptions
> + update docs
> + update skiboot.lid
>
>
> Aditya Gupta (7):
> ppc/pnv: Introduce Pnv11Chip
> ppc/pnv: Introduce Power11 PowerNV machine
> ppc/pnv: Add XIVE2 controller to Power11
> ppc/pnv: Add PHB5 PCIe Host bridge to Power11
> ppc/pnv: Add ChipTOD model for Power11
> tests/powernv: Switch to buildroot images instead of op-build
> tests/powernv: Add PowerNV test for Power11
>
> docs/system/ppc/powernv.rst | 9 +-
> hw/ppc/pnv.c | 540 +++++++++++++++++++++++++
> hw/ppc/pnv_chiptod.c | 59 +++
> hw/ppc/pnv_core.c | 17 +
> include/hw/ppc/pnv.h | 38 ++
> include/hw/ppc/pnv_chip.h | 7 +
> include/hw/ppc/pnv_chiptod.h | 2 +
> include/hw/ppc/pnv_xscom.h | 49 +++
> tests/functional/test_ppc64_powernv.py | 34 +-
> 9 files changed, 737 insertions(+), 18 deletions(-)
>
Booting a PowerNV11 machine crashes QEMU. See below.
Are you testing with petitboot kexecing a distro kernel from disk ?
Please do and also start a KVM guest. Please check your tests.
Thanks,
C.
[ 6.806342] e1000e 0001:02:03.0 eth0: MAC: 3, PHY: 8, PBA No: 000000-000
[ 6.844448] e1000e 0001:02:03.0 enP1p2s3: renamed from eth0
../include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object 0x555556ab0cf0 is not an instance of type pnv10-chip
Thread 1 "qemu-system-ppc" received signal SIGABRT, Aborted.
0x00007ffff6a8d02c in __pthread_kill_implementation () from /lib64/libc.so.6
Missing rpms, try: dnf --enablerepo='*debug*' install capstone-debuginfo-4.0.2-10.el9.x86_64 gnutls-debuginfo-3.8.3-9.el9.x86_64 pixman-debuginfo-0.40.0-6.el9.x86_64 zlib-debuginfo-1.2.11-40.el9.x86_64 lzo-debuginfo-2.10-7.el9.x86_64 SDL2-debuginfo-2.26.0-1.el9.x86_64 libpmem-debuginfo-1.12.1-1.el9.x86_64 libfdt-debuginfo-1.6.0-7.el9.x86_64 numactl-libs-debuginfo-2.0.19-1.el9.x86_64 glib2-debuginfo-2.68.4-16.el9_6.2.x86_64 libzstd-debuginfo-1.5.5-1.el9.x86_64 libslirp-debuginfo-4.4.0-8.el9.x86_64 elfutils-libs-debuginfo-0.193-1.el9.x86_64 ncurses-libs-debuginfo-6.2-12.20210508.el9.x86_64 usbredir-debuginfo-0.13.0-2.el9.x86_64 libusbx-debuginfo-1.0.26-1.el9.x86_64 glibc-debuginfo-2.34-221.el9.x86_64 p11-kit-debuginfo-0.25.3-3.el9.x86_64 libidn2-debuginfo-2.3.0-7.el9.x86_64 libunistring-debuginfo-0.9.10-15.el9.x86_64 libtasn1-debuginfo-4.16.0-9.el9.x86_64 nettle-debuginfo-3.10.1-1.el9.x86_64 ndctl-libs-debuginfo-78-2.el9.x86_64 daxctl-libs-debuginfo-78-2.el9.x86_64 libmount-debuginfo-2.37.4-21.el9.x86_64 libselinux-debuginfo-3.6-3.el9.x86_64 libffi-debuginfo-3.4.2-8.el9.x86_64 pcre-debuginfo-8.44-4.el9.x86_64 elfutils-libelf-debuginfo-0.193-1.el9.x86_64 xz-libs-debuginfo-5.2.5-8.el9_0.x86_64 bzip2-libs-debuginfo-1.0.8-10.el9_5.x86_64 systemd-libs-debuginfo-252-53.el9.x86_64 libuuid-debuginfo-2.37.4-21.el9.x86_64 kmod-libs-debuginfo-28-10.el9.x86_64 libblkid-debuginfo-2.37.4-21.el9.x86_64 pcre2-debuginfo-10.40-6.el9.x86_64 libgcc-debuginfo-11.5.0-9.el9.x86_64 openssl-libs-debuginfo-3.5.1-3.el9.x86_64
(gdb) bt
#0 0x00007ffff6a8d02c in __pthread_kill_implementation () at /lib64/libc.so.6
#1 0x00007ffff6a3fb86 in raise () at /lib64/libc.so.6
#2 0x00007ffff6a29873 in abort () at /lib64/libc.so.6
#3 0x0000555555d62988 in object_dynamic_cast_assert
(obj=0x555556ab0cf0, typename=typename@entry=0x5555560528a5 "pnv10-chip", file=file@entry=0x555556051628 "/home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h", line=line@entry=110, func=func@entry=0x55555606a2c8 <__func__.27> "PNV10_CHIP")
at ../qom/object.c:925
#4 0x0000555555cfe852 in PNV10_CHIP (obj=<optimized out>) at /home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h:110
#5 pnv_xive2_get_remote (fwd_addr=<optimized out>, vsd_type=2) at ../hw/intc/pnv_xive2.c:113
#6 pnv_xive2_vst_addr (idx=15, blk=<optimized out>, type=2, xive=<optimized out>) at ../hw/intc/pnv_xive2.c:265
#7 pnv_xive2_vst_addr (xive=<optimized out>, type=2, blk=<optimized out>, idx=15) at ../hw/intc/pnv_xive2.c:244
#8 0x0000555555cfec35 in pnv_xive2_vst_read (xive=0x555556ab1500, type=2, blk=1 '\001', idx=15, data=0x7fffffffcf20)
at ../hw/intc/pnv_xive2.c:286
#9 0x0000555555d06a69 in xive2_router_get_end (end=0x7fffffffcf20, end_idx=15, end_blk=1 '\001', xrtr=0x555556ab1500)
at ../hw/intc/xive2.c:1437
#10 xive2_router_end_notify
(xrtr=xrtr@entry=0x555556ab1500, end_blk=1 '\001', end_idx=15, end_data=97, redistribute=redistribute@entry=false)
at ../hw/intc/xive2.c:1669
#11 0x0000555555d06990 in xive2_notify (xrtr=0x555556ab1500, lisn=1040385, pq_checked=<optimized out>)
at ../hw/intc/xive2.c:1955
#12 0x0000555555add8bb in memory_region_write_accessor
(mr=mr@entry=0x555556ab3e00, addr=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, shift=<optimized out>, mask=mask@entry=18446744073709551615, attrs=...) at ../system/memory.c:490
#13 0x0000555555adf1a2 in access_with_adjusted_size
(addr=addr@entry=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x555556ab3e00, attrs=...)
at ../system/memory.c:561
#14 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x555556ab3e00, addr=136365408256, data=<optimized out>,
data@entry=0, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1553
#15 0x0000555555ae8357 in address_space_stq_internal
(as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=..., result=result@entry=0x7fffffffd1f4, endian=endian@entry=DEVICE_BIG_ENDIAN) at ../system/memory_ldst.c.inc:479
#16 0x0000555555aeef0b in address_space_stq_be
(as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=...,
attrs@entry=..., result=result@entry=0x7fffffffd1f4) at ../system/memory_ldst.c.inc:524
#17 0x0000555555d2159c in pnv_phb4_xive_notify_abt (pq_checked=false, srcno=<optimized out>, phb=0x5555574bc500)
at ../hw/pci-host/pnv_phb4.c:1650
#18 pnv_phb4_xive_notify (xf=<optimized out>, srcno=<optimized out>, pq_checked=<optimized out>)
at ../hw/pci-host/pnv_phb4.c:1686
#19 0x0000555555d203f0 in qemu_irq_pulse (irq=0x5555574c8440) at /home/legoater/work/qemu/qemu.git/include/hw/irq.h:33
#20 pnv_phb4_msi_write (opaque=<optimized out>, addr=<optimized out>, data=<optimized out>, size=<optimized out>)
at ../hw/pci-host/pnv_phb4.c:1423
#21 0x0000555555add8bb in memory_region_write_accessor
(mr=mr@entry=0x55555d8c76b0, addr=0, value=value@entry=0x7fffffffd318, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../system/memory.c:490
#22 0x0000555555adf23b in access_with_adjusted_size
(addr=addr@entry=0, value=value@entry=0x7fffffffd318, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x55555d8c76b0, attrs=...)
at ../system/memory.c:566
#23 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x55555d8c76b0, addr=0, data=<optimized out>,
data@entry=1, op=op@entry=MO_32, attrs=attrs@entry=...) at ../system/memory.c:1553
#24 0x0000555555aee333 in address_space_stl_internal
(endian=DEVICE_LITTLE_ENDIAN, result=0x0, attrs=..., val=1, addr=<optimized out>, as=<optimized out>)
at ../system/memory_ldst.c.inc:319
#25 address_space_stl_le (as=<optimized out>, addr=<optimized out>, val=1, attrs=..., result=0x0)
at ../system/memory_ldst.c.inc:357
#26 0x0000555555ef3c05 in aio_bh_call (bh=bh@entry=0x55555d0d59e0) at ../util/async.c:172
#27 0x0000555555ef3d35 in aio_bh_poll (ctx=ctx@entry=0x55555667ad50) at ../util/async.c:219
#28 0x0000555555edcede in aio_dispatch (ctx=0x55555667ad50) at ../util/aio-posix.c:436
#29 0x0000555555ef3a7e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
at ../util/async.c:361
#30 0x00007ffff76c0f4f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#31 0x0000555555ef5058 in glib_pollfds_poll () at ../util/main-loop.c:287
#32 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:310
#33 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589
#34 0x0000555555af89b3 in qemu_main_loop () at ../system/runstate.c:905
#35 0x0000555555e4273c in qemu_default_main (opaque=opaque@entry=0x0) at ../system/main.c:50
#36 0x000055555589eddd in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:93
Hi Cedric, Sorry for the late reply, I am on vacation this week, will try to look at this, but reply might be late. On 25/08/08 02:32PM, Cédric Le Goater wrote: > On 8/8/25 13:59, Aditya Gupta wrote: > > Overview > > ============ > > > > Add support for Power11 powernv machine type. > > > > > <...snip...> > > Booting a PowerNV11 machine crashes QEMU. See below. > > Are you testing with petitboot kexecing a distro kernel from disk ? > Please do and also start a KVM guest. Please check your tests. No, I ran the qemu functional tests, and few boot tests with different options. The functional test already attaches a e1000e device, somehow that didn't trigger the same error that you saw (maybe the kernel used doesn't have support for that device). Will add a test to try petitboot kexec scenario also, so we don't hit these kind of issues in future. Regarding KVM guest, iirc we can't start KVM guest for PowerNV yet right ? About the error, seems xive2 always expecting powernv10 chip, I will have to rethink how should I use the same xive2 for powernv11. Thank you for testing this Cedric ! - Aditya G > > Thanks, > > C. > > > [ 6.806342] e1000e 0001:02:03.0 eth0: MAC: 3, PHY: 8, PBA No: 000000-000 > [ 6.844448] e1000e 0001:02:03.0 enP1p2s3: renamed from eth0 > ../include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object 0x555556ab0cf0 is not an instance of type pnv10-chip > > Thread 1 "qemu-system-ppc" received signal SIGABRT, Aborted. > 0x00007ffff6a8d02c in __pthread_kill_implementation () from /lib64/libc.so.6 > Missing rpms, try: dnf --enablerepo='*debug*' install capstone-debuginfo-4.0.2-10.el9.x86_64 gnutls-debuginfo-3.8.3-9.el9.x86_64 pixman-debuginfo-0.40.0-6.el9.x86_64 zlib-debuginfo-1.2.11-40.el9.x86_64 lzo-debuginfo-2.10-7.el9.x86_64 SDL2-debuginfo-2.26.0-1.el9.x86_64 libpmem-debuginfo-1.12.1-1.el9.x86_64 libfdt-debuginfo-1.6.0-7.el9.x86_64 numactl-libs-debuginfo-2.0.19-1.el9.x86_64 glib2-debuginfo-2.68.4-16.el9_6.2.x86_64 libzstd-debuginfo-1.5.5-1.el9.x86_64 libslirp-debuginfo-4.4.0-8.el9.x86_64 elfutils-libs-debuginfo-0.193-1.el9.x86_64 ncurses-libs-debuginfo-6.2-12.20210508.el9.x86_64 usbredir-debuginfo-0.13.0-2.el9.x86_64 libusbx-debuginfo-1.0.26-1.el9.x86_64 glibc-debuginfo-2.34-221.el9.x86_64 p11-kit-debuginfo-0.25.3-3.el9.x86_64 libidn2-debuginfo-2.3.0-7.el9.x86_64 libunistring-debuginfo-0.9.10-15.el9.x86_64 libtasn1-debuginfo-4.16.0-9.el9.x86_64 nettle-debuginfo-3.10.1-1.el9.x86_64 ndctl-libs-debuginfo-78-2.el9.x86_64 daxctl-libs-debuginfo-78-2.el9.x86_64 libmount-debuginfo-2.37.4-21.el9.x86_64 libselinux-debuginfo-3.6-3.el9.x86_64 libffi-debuginfo-3.4.2-8.el9.x86_64 pcre-debuginfo-8.44-4.el9.x86_64 elfutils-libelf-debuginfo-0.193-1.el9.x86_64 xz-libs-debuginfo-5.2.5-8.el9_0.x86_64 bzip2-libs-debuginfo-1.0.8-10.el9_5.x86_64 systemd-libs-debuginfo-252-53.el9.x86_64 libuuid-debuginfo-2.37.4-21.el9.x86_64 kmod-libs-debuginfo-28-10.el9.x86_64 libblkid-debuginfo-2.37.4-21.el9.x86_64 pcre2-debuginfo-10.40-6.el9.x86_64 libgcc-debuginfo-11.5.0-9.el9.x86_64 openssl-libs-debuginfo-3.5.1-3.el9.x86_64 > (gdb) bt > #0 0x00007ffff6a8d02c in __pthread_kill_implementation () at /lib64/libc.so.6 > #1 0x00007ffff6a3fb86 in raise () at /lib64/libc.so.6 > #2 0x00007ffff6a29873 in abort () at /lib64/libc.so.6 > #3 0x0000555555d62988 in object_dynamic_cast_assert > (obj=0x555556ab0cf0, typename=typename@entry=0x5555560528a5 "pnv10-chip", file=file@entry=0x555556051628 "/home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h", line=line@entry=110, func=func@entry=0x55555606a2c8 <__func__.27> "PNV10_CHIP") > at ../qom/object.c:925 > #4 0x0000555555cfe852 in PNV10_CHIP (obj=<optimized out>) at /home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h:110 > #5 pnv_xive2_get_remote (fwd_addr=<optimized out>, vsd_type=2) at ../hw/intc/pnv_xive2.c:113 > #6 pnv_xive2_vst_addr (idx=15, blk=<optimized out>, type=2, xive=<optimized out>) at ../hw/intc/pnv_xive2.c:265 > #7 pnv_xive2_vst_addr (xive=<optimized out>, type=2, blk=<optimized out>, idx=15) at ../hw/intc/pnv_xive2.c:244 > #8 0x0000555555cfec35 in pnv_xive2_vst_read (xive=0x555556ab1500, type=2, blk=1 '\001', idx=15, data=0x7fffffffcf20) > at ../hw/intc/pnv_xive2.c:286 > #9 0x0000555555d06a69 in xive2_router_get_end (end=0x7fffffffcf20, end_idx=15, end_blk=1 '\001', xrtr=0x555556ab1500) > at ../hw/intc/xive2.c:1437 > #10 xive2_router_end_notify > (xrtr=xrtr@entry=0x555556ab1500, end_blk=1 '\001', end_idx=15, end_data=97, redistribute=redistribute@entry=false) > at ../hw/intc/xive2.c:1669 > #11 0x0000555555d06990 in xive2_notify (xrtr=0x555556ab1500, lisn=1040385, pq_checked=<optimized out>) > at ../hw/intc/xive2.c:1955 > #12 0x0000555555add8bb in memory_region_write_accessor > (mr=mr@entry=0x555556ab3e00, addr=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, shift=<optimized out>, mask=mask@entry=18446744073709551615, attrs=...) at ../system/memory.c:490 > #13 0x0000555555adf1a2 in access_with_adjusted_size > (addr=addr@entry=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x555556ab3e00, attrs=...) > at ../system/memory.c:561 > #14 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x555556ab3e00, addr=136365408256, data=<optimized out>, > data@entry=0, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1553 > #15 0x0000555555ae8357 in address_space_stq_internal > (as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=..., result=result@entry=0x7fffffffd1f4, endian=endian@entry=DEVICE_BIG_ENDIAN) at ../system/memory_ldst.c.inc:479 > #16 0x0000555555aeef0b in address_space_stq_be > (as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=..., > attrs@entry=..., result=result@entry=0x7fffffffd1f4) at ../system/memory_ldst.c.inc:524 > #17 0x0000555555d2159c in pnv_phb4_xive_notify_abt (pq_checked=false, srcno=<optimized out>, phb=0x5555574bc500) > at ../hw/pci-host/pnv_phb4.c:1650 > #18 pnv_phb4_xive_notify (xf=<optimized out>, srcno=<optimized out>, pq_checked=<optimized out>) > at ../hw/pci-host/pnv_phb4.c:1686 > #19 0x0000555555d203f0 in qemu_irq_pulse (irq=0x5555574c8440) at /home/legoater/work/qemu/qemu.git/include/hw/irq.h:33 > #20 pnv_phb4_msi_write (opaque=<optimized out>, addr=<optimized out>, data=<optimized out>, size=<optimized out>) > at ../hw/pci-host/pnv_phb4.c:1423 > #21 0x0000555555add8bb in memory_region_write_accessor > (mr=mr@entry=0x55555d8c76b0, addr=0, value=value@entry=0x7fffffffd318, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../system/memory.c:490 > #22 0x0000555555adf23b in access_with_adjusted_size > (addr=addr@entry=0, value=value@entry=0x7fffffffd318, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x55555d8c76b0, attrs=...) > at ../system/memory.c:566 > #23 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x55555d8c76b0, addr=0, data=<optimized out>, > data@entry=1, op=op@entry=MO_32, attrs=attrs@entry=...) at ../system/memory.c:1553 > #24 0x0000555555aee333 in address_space_stl_internal > (endian=DEVICE_LITTLE_ENDIAN, result=0x0, attrs=..., val=1, addr=<optimized out>, as=<optimized out>) > at ../system/memory_ldst.c.inc:319 > #25 address_space_stl_le (as=<optimized out>, addr=<optimized out>, val=1, attrs=..., result=0x0) > at ../system/memory_ldst.c.inc:357 > #26 0x0000555555ef3c05 in aio_bh_call (bh=bh@entry=0x55555d0d59e0) at ../util/async.c:172 > #27 0x0000555555ef3d35 in aio_bh_poll (ctx=ctx@entry=0x55555667ad50) at ../util/async.c:219 > #28 0x0000555555edcede in aio_dispatch (ctx=0x55555667ad50) at ../util/aio-posix.c:436 > #29 0x0000555555ef3a7e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) > at ../util/async.c:361 > #30 0x00007ffff76c0f4f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 > #31 0x0000555555ef5058 in glib_pollfds_poll () at ../util/main-loop.c:287 > #32 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:310 > #33 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589 > #34 0x0000555555af89b3 in qemu_main_loop () at ../system/runstate.c:905 > #35 0x0000555555e4273c in qemu_default_main (opaque=opaque@entry=0x0) at ../system/main.c:50 > #36 0x000055555589eddd in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:93 >
On 8/10/25 08:56, Aditya Gupta wrote:
> Hi Cedric,
> Sorry for the late reply, I am on vacation this week, will try to look
> at this, but reply might be late.
>
> On 25/08/08 02:32PM, Cédric Le Goater wrote:
>> On 8/8/25 13:59, Aditya Gupta wrote:
>>> Overview
>>> ============
>>>
>>> Add support for Power11 powernv machine type.
>>>
>>>> <...snip...>
>>
>> Booting a PowerNV11 machine crashes QEMU. See below.
>>
>> Are you testing with petitboot kexecing a distro kernel from disk ?
>> Please do and also start a KVM guest. Please check your tests.
>
> No, I ran the qemu functional tests, and few boot tests with different
> options.
>
> The functional test already attaches a e1000e device, somehow that
> didn't trigger the same error that you saw (maybe the kernel used
> doesn't have support for that device).
> Will add a test to try petitboot kexec scenario also, so we don't hit
> these kind of issues in future.
I run a multi socket config :
qemu-system-ppc64 -m 4G -machine powernv11 -smp 16,sockets=2,cores=2,threads=4 -accel tcg,thread=multi
-kernel ./zImage.epapr
-initrd ./rootfs.cpio.xz
-device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.0,addr=0x0,drive=drive0,serial=1234
-drive file=./Fedora-Cloud-Base-Generic-42-1.1.ppc64le.qcow2,if=none,id=drive0,format=qcow2,cache=none
-device e1000e,netdev=net0,mac=C0:FF:EE:00:01:05,bus=bridge1,addr=0x3
-netdev bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=net0
-device nec-usb-xhci,bus=bridge1,addr=0x2
-device usb-storage,drive=usbkey
-drive file=usb.img,if=none,id=usbkey,format=raw,cache=none
-serial mon:stdio -nographic
See :
https://lore.kernel.org/qemu-devel/3b1fcc0a-6ce7-4639-a17c-34d640745c20@redhat.com/
>
> Regarding KVM guest, iirc we can't start KVM guest for PowerNV yet right
> ?
The QEMU PowerNV machines support emulated KVM guests. XIVE
is a key component in its support, as it controls the wake-up
of the virtual processors.
The QEMU pseries machines support nested too, both implementations:
the initial on OPAL systems and the most recent v2 one for pHyp.
I believe QEMU PowerNV machines support nested KVM too. Never
tried that though.
C.
On 25/08/10 12:26PM, Aditya Gupta wrote:
> > <...snip...>
>
> About the error, seems xive2 always expecting powernv10 chip, I will
> have to rethink how should I use the same xive2 for powernv11.
>
There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
The cast is only temporarily used to get the 'PnvXive2' object in the
Pnv10Chip.
It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
Thinking to have a helper function to just return the 'PnvXive2' object
inside the chip, given a 'PnvChip'.
Or the below change where we are adding another pointer in PnvChipClass:
diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
index e019cad5c14c..9832be5fd297 100644
--- a/hw/intc/pnv_xive2.c
+++ b/hw/intc/pnv_xive2.c
@@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
int i;
for (i = 0; i < pnv->num_chips; i++) {
- Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
- PnvXive2 *xive = &chip10->xive;
+ PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
+ PnvXive2 *xive = k->intc_get(pnv->chips[i]);
/*
* Is this the XIVE matching the forwarded VSD address is for this
Which one do you suggest ? Or should I look for another way ?
I am preferring the first way to have a helper, but both ways look hacky.
Attaching complete patch at end of the message.
Thanks,
- Aditya G
> >
> > Thanks,
> >
> > C.
> >
> >
> > [ 6.806342] e1000e 0001:02:03.0 eth0: MAC: 3, PHY: 8, PBA No: 000000-000
> > [ 6.844448] e1000e 0001:02:03.0 enP1p2s3: renamed from eth0
> > ../include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object 0x555556ab0cf0 is not an instance of type pnv10-chip
> >
> > Thread 1 "qemu-system-ppc" received signal SIGABRT, Aborted.
> > 0x00007ffff6a8d02c in __pthread_kill_implementation () from /lib64/libc.so.6
> > Missing rpms, try: dnf --enablerepo='*debug*' install capstone-debuginfo-4.0.2-10.el9.x86_64 gnutls-debuginfo-3.8.3-9.el9.x86_64 pixman-debuginfo-0.40.0-6.el9.x86_64 zlib-debuginfo-1.2.11-40.el9.x86_64 lzo-debuginfo-2.10-7.el9.x86_64 SDL2-debuginfo-2.26.0-1.el9.x86_64 libpmem-debuginfo-1.12.1-1.el9.x86_64 libfdt-debuginfo-1.6.0-7.el9.x86_64 numactl-libs-debuginfo-2.0.19-1.el9.x86_64 glib2-debuginfo-2.68.4-16.el9_6.2.x86_64 libzstd-debuginfo-1.5.5-1.el9.x86_64 libslirp-debuginfo-4.4.0-8.el9.x86_64 elfutils-libs-debuginfo-0.193-1.el9.x86_64 ncurses-libs-debuginfo-6.2-12.20210508.el9.x86_64 usbredir-debuginfo-0.13.0-2.el9.x86_64 libusbx-debuginfo-1.0.26-1.el9.x86_64 glibc-debuginfo-2.34-221.el9.x86_64 p11-kit-debuginfo-0.25.3-3.el9.x86_64 libidn2-debuginfo-2.3.0-7.el9.x86_64 libunistring-debuginfo-0.9.10-15.el9.x86_64 libtasn1-debuginfo-4.16.0-9.el9.x86_64 nettle-debuginfo-3.10.1-1.el9.x86_64 ndctl-libs-debuginfo-78-2.el9.x86_64 daxctl-libs-debuginfo-78-2.el9.x86_64 libmount-debuginfo-2.37.4-21.el9.x86_64 libselinux-debuginfo-3.6-3.el9.x86_64 libffi-debuginfo-3.4.2-8.el9.x86_64 pcre-debuginfo-8.44-4.el9.x86_64 elfutils-libelf-debuginfo-0.193-1.el9.x86_64 xz-libs-debuginfo-5.2.5-8.el9_0.x86_64 bzip2-libs-debuginfo-1.0.8-10.el9_5.x86_64 systemd-libs-debuginfo-252-53.el9.x86_64 libuuid-debuginfo-2.37.4-21.el9.x86_64 kmod-libs-debuginfo-28-10.el9.x86_64 libblkid-debuginfo-2.37.4-21.el9.x86_64 pcre2-debuginfo-10.40-6.el9.x86_64 libgcc-debuginfo-11.5.0-9.el9.x86_64 openssl-libs-debuginfo-3.5.1-3.el9.x86_64
> > (gdb) bt
> > #0 0x00007ffff6a8d02c in __pthread_kill_implementation () at /lib64/libc.so.6
> > #1 0x00007ffff6a3fb86 in raise () at /lib64/libc.so.6
> > #2 0x00007ffff6a29873 in abort () at /lib64/libc.so.6
> > #3 0x0000555555d62988 in object_dynamic_cast_assert
> > (obj=0x555556ab0cf0, typename=typename@entry=0x5555560528a5 "pnv10-chip", file=file@entry=0x555556051628 "/home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h", line=line@entry=110, func=func@entry=0x55555606a2c8 <__func__.27> "PNV10_CHIP")
> > at ../qom/object.c:925
> > #4 0x0000555555cfe852 in PNV10_CHIP (obj=<optimized out>) at /home/legoater/work/qemu/qemu.git/include/hw/ppc/pnv_chip.h:110
> > #5 pnv_xive2_get_remote (fwd_addr=<optimized out>, vsd_type=2) at ../hw/intc/pnv_xive2.c:113
> > #6 pnv_xive2_vst_addr (idx=15, blk=<optimized out>, type=2, xive=<optimized out>) at ../hw/intc/pnv_xive2.c:265
> > #7 pnv_xive2_vst_addr (xive=<optimized out>, type=2, blk=<optimized out>, idx=15) at ../hw/intc/pnv_xive2.c:244
> > #8 0x0000555555cfec35 in pnv_xive2_vst_read (xive=0x555556ab1500, type=2, blk=1 '\001', idx=15, data=0x7fffffffcf20)
> > at ../hw/intc/pnv_xive2.c:286
> > #9 0x0000555555d06a69 in xive2_router_get_end (end=0x7fffffffcf20, end_idx=15, end_blk=1 '\001', xrtr=0x555556ab1500)
> > at ../hw/intc/xive2.c:1437
> > #10 xive2_router_end_notify
> > (xrtr=xrtr@entry=0x555556ab1500, end_blk=1 '\001', end_idx=15, end_data=97, redistribute=redistribute@entry=false)
> > at ../hw/intc/xive2.c:1669
> > #11 0x0000555555d06990 in xive2_notify (xrtr=0x555556ab1500, lisn=1040385, pq_checked=<optimized out>)
> > at ../hw/intc/xive2.c:1955
> > #12 0x0000555555add8bb in memory_region_write_accessor
> > (mr=mr@entry=0x555556ab3e00, addr=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, shift=<optimized out>, mask=mask@entry=18446744073709551615, attrs=...) at ../system/memory.c:490
> > #13 0x0000555555adf1a2 in access_with_adjusted_size
> > (addr=addr@entry=136365408256, value=value@entry=0x7fffffffd0e8, size=size@entry=8, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x555556ab3e00, attrs=...)
> > at ../system/memory.c:561
> > #14 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x555556ab3e00, addr=136365408256, data=<optimized out>,
> > data@entry=0, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1553
> > #15 0x0000555555ae8357 in address_space_stq_internal
> > (as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=..., result=result@entry=0x7fffffffd1f4, endian=endian@entry=DEVICE_BIG_ENDIAN) at ../system/memory_ldst.c.inc:479
> > #16 0x0000555555aeef0b in address_space_stq_be
> > (as=<optimized out>, addr=addr@entry=1694483783811072, val=val@entry=0, attrs=...,
> > attrs@entry=..., result=result@entry=0x7fffffffd1f4) at ../system/memory_ldst.c.inc:524
> > #17 0x0000555555d2159c in pnv_phb4_xive_notify_abt (pq_checked=false, srcno=<optimized out>, phb=0x5555574bc500)
> > at ../hw/pci-host/pnv_phb4.c:1650
> > #18 pnv_phb4_xive_notify (xf=<optimized out>, srcno=<optimized out>, pq_checked=<optimized out>)
> > at ../hw/pci-host/pnv_phb4.c:1686
> > #19 0x0000555555d203f0 in qemu_irq_pulse (irq=0x5555574c8440) at /home/legoater/work/qemu/qemu.git/include/hw/irq.h:33
> > #20 pnv_phb4_msi_write (opaque=<optimized out>, addr=<optimized out>, data=<optimized out>, size=<optimized out>)
> > at ../hw/pci-host/pnv_phb4.c:1423
> > #21 0x0000555555add8bb in memory_region_write_accessor
> > (mr=mr@entry=0x55555d8c76b0, addr=0, value=value@entry=0x7fffffffd318, size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../system/memory.c:490
> > #22 0x0000555555adf23b in access_with_adjusted_size
> > (addr=addr@entry=0, value=value@entry=0x7fffffffd318, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x555555add850 <memory_region_write_accessor>, mr=0x55555d8c76b0, attrs=...)
> > at ../system/memory.c:566
> > #23 0x0000555555ae0164 in memory_region_dispatch_write (mr=mr@entry=0x55555d8c76b0, addr=0, data=<optimized out>,
> > data@entry=1, op=op@entry=MO_32, attrs=attrs@entry=...) at ../system/memory.c:1553
> > #24 0x0000555555aee333 in address_space_stl_internal
> > (endian=DEVICE_LITTLE_ENDIAN, result=0x0, attrs=..., val=1, addr=<optimized out>, as=<optimized out>)
> > at ../system/memory_ldst.c.inc:319
> > #25 address_space_stl_le (as=<optimized out>, addr=<optimized out>, val=1, attrs=..., result=0x0)
> > at ../system/memory_ldst.c.inc:357
> > #26 0x0000555555ef3c05 in aio_bh_call (bh=bh@entry=0x55555d0d59e0) at ../util/async.c:172
> > #27 0x0000555555ef3d35 in aio_bh_poll (ctx=ctx@entry=0x55555667ad50) at ../util/async.c:219
> > #28 0x0000555555edcede in aio_dispatch (ctx=0x55555667ad50) at ../util/aio-posix.c:436
> > #29 0x0000555555ef3a7e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
> > at ../util/async.c:361
> > #30 0x00007ffff76c0f4f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> > #31 0x0000555555ef5058 in glib_pollfds_poll () at ../util/main-loop.c:287
> > #32 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:310
> > #33 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589
> > #34 0x0000555555af89b3 in qemu_main_loop () at ../system/runstate.c:905
> > #35 0x0000555555e4273c in qemu_default_main (opaque=opaque@entry=0x0) at ../system/main.c:50
> > #36 0x000055555589eddd in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:93
> >
The patch which fixes the issue, adding another pointer in PnvChipClass:
diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
index e019cad5c14c..9832be5fd297 100644
--- a/hw/intc/pnv_xive2.c
+++ b/hw/intc/pnv_xive2.c
@@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
int i;
for (i = 0; i < pnv->num_chips; i++) {
- Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
- PnvXive2 *xive = &chip10->xive;
+ PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
+ PnvXive2 *xive = k->intc_get(pnv->chips[i]);
/*
* Is this the XIVE matching the forwarded VSD address is for this
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 673bb54c6789..81889ede2e0c 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1488,6 +1488,11 @@ static void pnv_chip_power10_intc_print_info(PnvChip *chip, PowerPCCPU *cpu,
xive_tctx_pic_print_info(XIVE_TCTX(pnv_cpu_state(cpu)->intc), buf);
}
+static PnvXive2 *pnv_chip_power10_intc_get(PnvChip *chip)
+{
+ return &PNV10_CHIP(chip)->xive;
+}
+
static void pnv_chip_power11_intc_create(PnvChip *chip, PowerPCCPU *cpu,
Error **errp)
{
@@ -1532,6 +1537,11 @@ static void pnv_chip_power11_intc_print_info(PnvChip *chip, PowerPCCPU *cpu,
xive_tctx_pic_print_info(XIVE_TCTX(pnv_cpu_state(cpu)->intc), buf);
}
+static PnvXive2 *pnv_chip_power11_intc_get(PnvChip *chip)
+{
+ return &PNV11_CHIP(chip)->xive;
+}
+
/*
* Allowed core identifiers on a POWER8 Processor Chip :
*
@@ -2716,6 +2726,7 @@ static void pnv_chip_power10_class_init(ObjectClass *klass, const void *data)
k->intc_reset = pnv_chip_power10_intc_reset;
k->intc_destroy = pnv_chip_power10_intc_destroy;
k->intc_print_info = pnv_chip_power10_intc_print_info;
+ k->intc_get = pnv_chip_power10_intc_get;
k->isa_create = pnv_chip_power10_isa_create;
k->dt_populate = pnv_chip_power10_dt_populate;
k->pic_print_info = pnv_chip_power10_pic_print_info;
@@ -2749,6 +2760,7 @@ static void pnv_chip_power11_class_init(ObjectClass *klass, const void *data)
k->intc_reset = pnv_chip_power11_intc_reset;
k->intc_destroy = pnv_chip_power11_intc_destroy;
k->intc_print_info = pnv_chip_power11_intc_print_info;
+ k->intc_get = pnv_chip_power11_intc_get;
k->isa_create = pnv_chip_power11_isa_create;
k->dt_populate = pnv_chip_power11_dt_populate;
k->pic_print_info = pnv_chip_power11_pic_print_info;
diff --git a/include/hw/ppc/pnv_chip.h b/include/hw/ppc/pnv_chip.h
index 6bd930f8b439..dcdbf519f894 100644
--- a/include/hw/ppc/pnv_chip.h
+++ b/include/hw/ppc/pnv_chip.h
@@ -170,6 +170,7 @@ struct PnvChipClass {
void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_destroy)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_print_info)(PnvChip *chip, PowerPCCPU *cpu, GString *buf);
+ PnvXive2* (*intc_get)(PnvChip *chip);
ISABus *(*isa_create)(PnvChip *chip, Error **errp);
void (*dt_populate)(PnvChip *chip, void *fdt);
void (*pic_print_info)(PnvChip *chip, GString *buf);
+ Glenn
+ Gautam
On 8/10/25 12:45, Aditya Gupta wrote:
> On 25/08/10 12:26PM, Aditya Gupta wrote:
>>> <...snip...>
>>
>> About the error, seems xive2 always expecting powernv10 chip, I will
>> have to rethink how should I use the same xive2 for powernv11.
>>
>
> There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
> The cast is only temporarily used to get the 'PnvXive2' object in the
> Pnv10Chip.
> It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
>
> Thinking to have a helper function to just return the 'PnvXive2' object
> inside the chip, given a 'PnvChip'.
>
> Or the below change where we are adding another pointer in PnvChipClass:
>
> diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
> index e019cad5c14c..9832be5fd297 100644
> --- a/hw/intc/pnv_xive2.c
> +++ b/hw/intc/pnv_xive2.c
> @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
> int i;
>
> for (i = 0; i < pnv->num_chips; i++) {
> - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
> - PnvXive2 *xive = &chip10->xive;
> + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
> + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
>
> /*
> * Is this the XIVE matching the forwarded VSD address is for this
>
> Which one do you suggest ? Or should I look for another way ?
>
> I am preferring the first way to have a helper, but both ways look hacky.
Any call to qdev_get_machine() in device model is at best
a modeling shortcut, most likely it is a hack :
/*
* Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
* scan of all the chips INT controller is good enough.
*/
So all these calls are suspicious :
$ git grep qdev_get_machine hw/*/*pnv*
hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
In the particular case of XIVE2, the solution is to rework
pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
("ppc/xive: Add support for the PC MMIOs").
Thanks,
C.
+ Ganesh
On 25/08/10 02:46PM, Cédric Le Goater wrote:
> + Glenn
> + Gautam
>
> On 8/10/25 12:45, Aditya Gupta wrote:
> > On 25/08/10 12:26PM, Aditya Gupta wrote:
> > > > <...snip...>
> > >
> > > About the error, seems xive2 always expecting powernv10 chip, I will
> > > have to rethink how should I use the same xive2 for powernv11.
> > >
> >
> > There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
> > The cast is only temporarily used to get the 'PnvXive2' object in the
> > Pnv10Chip.
> > It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
> >
> > Thinking to have a helper function to just return the 'PnvXive2' object
> > inside the chip, given a 'PnvChip'.
> >
> > Or the below change where we are adding another pointer in PnvChipClass:
> >
> > diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
> > index e019cad5c14c..9832be5fd297 100644
> > --- a/hw/intc/pnv_xive2.c
> > +++ b/hw/intc/pnv_xive2.c
> > @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
> > int i;
> > for (i = 0; i < pnv->num_chips; i++) {
> > - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
> > - PnvXive2 *xive = &chip10->xive;
> > + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
> > + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
> > /*
> > * Is this the XIVE matching the forwarded VSD address is for this
> >
> > Which one do you suggest ? Or should I look for another way ?
> >
> > I am preferring the first way to have a helper, but both ways look hacky.
>
> Any call to qdev_get_machine() in device model is at best
> a modeling shortcut, most likely it is a hack :
>
> /*
> * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
> * scan of all the chips INT controller is good enough.
> */
>
> So all these calls are suspicious :
>
> $ git grep qdev_get_machine hw/*/*pnv*
> hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>
> In the particular case of XIVE2, the solution is to rework
> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
> ("ppc/xive: Add support for the PC MMIOs").
>
Hi Cedric,
While I am working with XIVE engineers to get the pnv_xive2_get_remote()
reworked as suggested (since it's a bit more work due to multiple cases
of indirect/direct vst, nvg/nvc types in case of XIVE2), I would like
to propose below patch to have as an interim solution to unblock
the PowerNV11 support patches.
Please let me know if it looks good to you.
I am planning to have this as part of the pnv11 patches.
diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
index e019cad5c14c..0663baab544c 100644
--- a/hw/intc/pnv_xive2.c
+++ b/hw/intc/pnv_xive2.c
@@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
int i;
for (i = 0; i < pnv->num_chips; i++) {
- Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
- PnvXive2 *xive = &chip10->xive;
+ PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
+ PnvXive2 *xive = PNV_XIVE2(k->intc_get(pnv->chips[i]));
/*
* Is this the XIVE matching the forwarded VSD address is for this
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 673bb54c6789..907e029c51eb 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1488,6 +1488,11 @@ static void pnv_chip_power10_intc_print_info(PnvChip *chip, PowerPCCPU *cpu,
xive_tctx_pic_print_info(XIVE_TCTX(pnv_cpu_state(cpu)->intc), buf);
}
+static void *pnv_chip_power10_intc_get(PnvChip *chip)
+{
+ return &PNV10_CHIP(chip)->xive;
+}
+
static void pnv_chip_power11_intc_create(PnvChip *chip, PowerPCCPU *cpu,
Error **errp)
{
@@ -1532,6 +1537,11 @@ static void pnv_chip_power11_intc_print_info(PnvChip *chip, PowerPCCPU *cpu,
xive_tctx_pic_print_info(XIVE_TCTX(pnv_cpu_state(cpu)->intc), buf);
}
+static void *pnv_chip_power11_intc_get(PnvChip *chip)
+{
+ return &PNV11_CHIP(chip)->xive;
+}
+
/*
* Allowed core identifiers on a POWER8 Processor Chip :
*
@@ -2716,6 +2726,7 @@ static void pnv_chip_power10_class_init(ObjectClass *klass, const void *data)
k->intc_reset = pnv_chip_power10_intc_reset;
k->intc_destroy = pnv_chip_power10_intc_destroy;
k->intc_print_info = pnv_chip_power10_intc_print_info;
+ k->intc_get = pnv_chip_power10_intc_get;
k->isa_create = pnv_chip_power10_isa_create;
k->dt_populate = pnv_chip_power10_dt_populate;
k->pic_print_info = pnv_chip_power10_pic_print_info;
@@ -2749,6 +2760,7 @@ static void pnv_chip_power11_class_init(ObjectClass *klass, const void *data)
k->intc_reset = pnv_chip_power11_intc_reset;
k->intc_destroy = pnv_chip_power11_intc_destroy;
k->intc_print_info = pnv_chip_power11_intc_print_info;
+ k->intc_get = pnv_chip_power11_intc_get;
k->isa_create = pnv_chip_power11_isa_create;
k->dt_populate = pnv_chip_power11_dt_populate;
k->pic_print_info = pnv_chip_power11_pic_print_info;
diff --git a/include/hw/ppc/pnv_chip.h b/include/hw/ppc/pnv_chip.h
index 6bd930f8b439..a5b8c49680d3 100644
--- a/include/hw/ppc/pnv_chip.h
+++ b/include/hw/ppc/pnv_chip.h
@@ -170,6 +170,7 @@ struct PnvChipClass {
void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_destroy)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_print_info)(PnvChip *chip, PowerPCCPU *cpu, GString *buf);
+ void* (*intc_get)(PnvChip *chip);
ISABus *(*isa_create)(PnvChip *chip, Error **errp);
void (*dt_populate)(PnvChip *chip, void *fdt);
void (*pic_print_info)(PnvChip *chip, GString *buf);
Thanks,
- Aditya G
On 8/28/25 14:04, Aditya Gupta wrote:
> + Ganesh
>
> On 25/08/10 02:46PM, Cédric Le Goater wrote:
>> + Glenn
>> + Gautam
>>
>> On 8/10/25 12:45, Aditya Gupta wrote:
>>> On 25/08/10 12:26PM, Aditya Gupta wrote:
>>>>> <...snip...>
>>>>
>>>> About the error, seems xive2 always expecting powernv10 chip, I will
>>>> have to rethink how should I use the same xive2 for powernv11.
>>>>
>>>
>>> There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
>>> The cast is only temporarily used to get the 'PnvXive2' object in the
>>> Pnv10Chip.
>>> It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
>>>
>>> Thinking to have a helper function to just return the 'PnvXive2' object
>>> inside the chip, given a 'PnvChip'.
>>>
>>> Or the below change where we are adding another pointer in PnvChipClass:
>>>
>>> diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
>>> index e019cad5c14c..9832be5fd297 100644
>>> --- a/hw/intc/pnv_xive2.c
>>> +++ b/hw/intc/pnv_xive2.c
>>> @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
>>> int i;
>>> for (i = 0; i < pnv->num_chips; i++) {
>>> - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
>>> - PnvXive2 *xive = &chip10->xive;
>>> + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
>>> + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
>>> /*
>>> * Is this the XIVE matching the forwarded VSD address is for this
>>>
>>> Which one do you suggest ? Or should I look for another way ?
>>>
>>> I am preferring the first way to have a helper, but both ways look hacky.
>>
>> Any call to qdev_get_machine() in device model is at best
>> a modeling shortcut, most likely it is a hack :
>>
>> /*
>> * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
>> * scan of all the chips INT controller is good enough.
>> */
>>
>> So all these calls are suspicious :
>>
>> $ git grep qdev_get_machine hw/*/*pnv*
>> hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>> hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>
>> In the particular case of XIVE2, the solution is to rework
>> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
>> ("ppc/xive: Add support for the PC MMIOs").
>>
>
> Hi Cedric,
>
> While I am working with XIVE engineers to get the pnv_xive2_get_remote()
> reworked as suggested (since it's a bit more work due to multiple cases
> of indirect/direct vst, nvg/nvc types in case of XIVE2), I would like
> to propose below patch to have as an interim solution to unblock
> the PowerNV11 support patches.
pHyp is an unknown FW implementation for opensource. Until an image
is released somewhere (please think about it), QEMU has nothing to
worry about other than supporting OPAL.
For now, let's forget about the grouping aspect of XIVE2, simply
rework pnv_xive2_get_remote() as it was done in b68147b7a5bf for
XIVE. This shouldn't take long. And, for the nvg/nvc types, report
an error of some sort and add a TODO in the code.
>
> Please let me know if it looks good to you.
It's a hack. So please try the above first.
Thanks,
C.
On 8/29/25 3:19 AM, Cédric Le Goater wrote:
> On 8/28/25 14:04, Aditya Gupta wrote:
>> + Ganesh
>>
>> On 25/08/10 02:46PM, Cédric Le Goater wrote:
>>> + Glenn
>>> + Gautam
>>>
>>> On 8/10/25 12:45, Aditya Gupta wrote:
>>>> On 25/08/10 12:26PM, Aditya Gupta wrote:
>>>>>> <...snip...>
>>>>>
>>>>> About the error, seems xive2 always expecting powernv10 chip, I will
>>>>> have to rethink how should I use the same xive2 for powernv11.
>>>>>
>>>>
>>>> There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
>>>> The cast is only temporarily used to get the 'PnvXive2' object in the
>>>> Pnv10Chip.
>>>> It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
>>>>
>>>> Thinking to have a helper function to just return the 'PnvXive2' object
>>>> inside the chip, given a 'PnvChip'.
>>>>
>>>> Or the below change where we are adding another pointer in
>>>> PnvChipClass:
>>>>
>>>> diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
>>>> index e019cad5c14c..9832be5fd297 100644
>>>> --- a/hw/intc/pnv_xive2.c
>>>> +++ b/hw/intc/pnv_xive2.c
>>>> @@ -110,8 +110,8 @@ static PnvXive2
>>>> *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
>>>> int i;
>>>> for (i = 0; i < pnv->num_chips; i++) {
>>>> - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
>>>> - PnvXive2 *xive = &chip10->xive;
>>>> + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
>>>> + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
>>>> /*
>>>> * Is this the XIVE matching the forwarded VSD
>>>> address is for this
>>>>
>>>> Which one do you suggest ? Or should I look for another way ?
>>>>
>>>> I am preferring the first way to have a helper, but both ways look
>>>> hacky.
>>>
>>> Any call to qdev_get_machine() in device model is at best
>>> a modeling shortcut, most likely it is a hack :
>>>
>>> /*
>>> * Remote access to INT controllers. HW uses MMIOs(?). For now, a
>>> simple
>>> * scan of all the chips INT controller is good enough.
>>> */
>>>
>>> So all these calls are suspicious :
>>>
>>> $ git grep qdev_get_machine hw/*/*pnv*
>>> hw/intc/pnv_xive2.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/pci-host/pnv_phb.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/ppc/pnv.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/ppc/pnv.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>> hw/ppc/pnv_lpc.c: PnvMachineState *pnv =
>>> PNV_MACHINE(qdev_get_machine());
>>>
>>> In the particular case of XIVE2, the solution is to rework
>>> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
>>> ("ppc/xive: Add support for the PC MMIOs").
>>>
>>
>> Hi Cedric,
>>
>> While I am working with XIVE engineers to get the pnv_xive2_get_remote()
>> reworked as suggested (since it's a bit more work due to multiple cases
>> of indirect/direct vst, nvg/nvc types in case of XIVE2), I would like
>> to propose below patch to have as an interim solution to unblock
>> the PowerNV11 support patches.
>
> pHyp is an unknown FW implementation for opensource. Until an image
> is released somewhere (please think about it), QEMU has nothing to
> worry about other than supporting OPAL.
>
> For now, let's forget about the grouping aspect of XIVE2, simply
> rework pnv_xive2_get_remote() as it was done in b68147b7a5bf for
> XIVE. This shouldn't take long. And, for the nvg/nvc types, report
> an error of some sort and add a TODO in the code.
>
A similar change cannot be done to XIVE2, because Fredric’s commit
(96a2132ce95) has introduced modifications to the NVPG and NVC MMIO
callbacks in order to support backlog counter operations.
>>
>> Please let me know if it looks good to you.
>
> It's a hack. So please try the above first.
>
>
> Thanks,
>
> C.
>
On 9/24/25 14:14, Ganesh G R wrote:
>
> On 8/29/25 3:19 AM, Cédric Le Goater wrote:
>> On 8/28/25 14:04, Aditya Gupta wrote:
>>> + Ganesh
>>>
>>> On 25/08/10 02:46PM, Cédric Le Goater wrote:
>>>> + Glenn
>>>> + Gautam
>>>>
>>>> On 8/10/25 12:45, Aditya Gupta wrote:
>>>>> On 25/08/10 12:26PM, Aditya Gupta wrote:
>>>>>>> <...snip...>
>>>>>>
>>>>>> About the error, seems xive2 always expecting powernv10 chip, I will
>>>>>> have to rethink how should I use the same xive2 for powernv11.
>>>>>>
>>>>>
>>>>> There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
>>>>> The cast is only temporarily used to get the 'PnvXive2' object in the
>>>>> Pnv10Chip.
>>>>> It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
>>>>>
>>>>> Thinking to have a helper function to just return the 'PnvXive2' object
>>>>> inside the chip, given a 'PnvChip'.
>>>>>
>>>>> Or the below change where we are adding another pointer in PnvChipClass:
>>>>>
>>>>> diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
>>>>> index e019cad5c14c..9832be5fd297 100644
>>>>> --- a/hw/intc/pnv_xive2.c
>>>>> +++ b/hw/intc/pnv_xive2.c
>>>>> @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
>>>>> int i;
>>>>> for (i = 0; i < pnv->num_chips; i++) {
>>>>> - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
>>>>> - PnvXive2 *xive = &chip10->xive;
>>>>> + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
>>>>> + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
>>>>> /*
>>>>> * Is this the XIVE matching the forwarded VSD address is for this
>>>>>
>>>>> Which one do you suggest ? Or should I look for another way ?
>>>>>
>>>>> I am preferring the first way to have a helper, but both ways look hacky.
>>>>
>>>> Any call to qdev_get_machine() in device model is at best
>>>> a modeling shortcut, most likely it is a hack :
>>>>
>>>> /*
>>>> * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
>>>> * scan of all the chips INT controller is good enough.
>>>> */
>>>>
>>>> So all these calls are suspicious :
>>>>
>>>> $ git grep qdev_get_machine hw/*/*pnv*
>>>> hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>> hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>>>>
>>>> In the particular case of XIVE2, the solution is to rework
>>>> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
>>>> ("ppc/xive: Add support for the PC MMIOs").
>>>>
>>>
>>> Hi Cedric,
>>>
>>> While I am working with XIVE engineers to get the pnv_xive2_get_remote()
>>> reworked as suggested (since it's a bit more work due to multiple cases
>>> of indirect/direct vst, nvg/nvc types in case of XIVE2), I would like
>>> to propose below patch to have as an interim solution to unblock
>>> the PowerNV11 support patches.
>>
>> pHyp is an unknown FW implementation for opensource. Until an image
>> is released somewhere (please think about it), QEMU has nothing to
>> worry about other than supporting OPAL.
>>
>> For now, let's forget about the grouping aspect of XIVE2, simply
>> rework pnv_xive2_get_remote() as it was done in b68147b7a5bf for
>> XIVE. This shouldn't take long. And, for the nvg/nvc types, report
>> an error of some sort and add a TODO in the code.
>>
> A similar change cannot be done to XIVE2, because Fredric’s commit (96a2132ce95) has introduced modifications to the NVPG and NVC MMIO callbacks in order to support backlog counter operations.
Thanks for looking.
Indeed. So I guess Aditya's proposal adding a new PnvChipClass handler
is then the best alternative :
@@ -170,6 +170,7 @@ struct PnvChipClass {
void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_destroy)(PnvChip *chip, PowerPCCPU *cpu);
void (*intc_print_info)(PnvChip *chip, PowerPCCPU *cpu, GString *buf);
+ void* (*intc_get)(PnvChip *chip);
ISABus *(*isa_create)(PnvChip *chip, Error **errp);
void (*dt_populate)(PnvChip *chip, void *fdt);
void (*pic_print_info)(PnvChip *chip, GString *buf);
Aditya,
Could you please resend the whole powernv11 series including this
new patch for xive2 ?
Thanks,
C.
On 25/09/25 08:38AM, Cédric Le Goater wrote:
> On 9/24/25 14:14, Ganesh G R wrote:
> >
> > On 8/29/25 3:19 AM, Cédric Le Goater wrote:
> > > On 8/28/25 14:04, Aditya Gupta wrote:
> > > > + Ganesh
> > > >
> > > > On 25/08/10 02:46PM, Cédric Le Goater wrote:
> > > > > + Glenn
> > > > > + Gautam
> > > > >
> > > > > On 8/10/25 12:45, Aditya Gupta wrote:
> > > > > > On 25/08/10 12:26PM, Aditya Gupta wrote:
> > > > > > > > <...snip...>
> > > > > > >
> > > > > > > About the error, seems xive2 always expecting powernv10 chip, I will
> > > > > > > have to rethink how should I use the same xive2 for powernv11.
> > > > > > >
> > > > > >
> > > > > > There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
> > > > > > The cast is only temporarily used to get the 'PnvXive2' object in the
> > > > > > Pnv10Chip.
> > > > > > It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
> > > > > >
> > > > > > Thinking to have a helper function to just return the 'PnvXive2' object
> > > > > > inside the chip, given a 'PnvChip'.
> > > > > >
> > > > > > Or the below change where we are adding another pointer in PnvChipClass:
> > > > > >
> > > > > > diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
> > > > > > index e019cad5c14c..9832be5fd297 100644
> > > > > > --- a/hw/intc/pnv_xive2.c
> > > > > > +++ b/hw/intc/pnv_xive2.c
> > > > > > @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
> > > > > > int i;
> > > > > > for (i = 0; i < pnv->num_chips; i++) {
> > > > > > - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
> > > > > > - PnvXive2 *xive = &chip10->xive;
> > > > > > + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
> > > > > > + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
> > > > > > /*
> > > > > > * Is this the XIVE matching the forwarded VSD address is for this
> > > > > >
> > > > > > Which one do you suggest ? Or should I look for another way ?
> > > > > >
> > > > > > I am preferring the first way to have a helper, but both ways look hacky.
> > > > >
> > > > > Any call to qdev_get_machine() in device model is at best
> > > > > a modeling shortcut, most likely it is a hack :
> > > > >
> > > > > /*
> > > > > * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
> > > > > * scan of all the chips INT controller is good enough.
> > > > > */
> > > > >
> > > > > So all these calls are suspicious :
> > > > >
> > > > > $ git grep qdev_get_machine hw/*/*pnv*
> > > > > hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > > hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> > > > >
> > > > > In the particular case of XIVE2, the solution is to rework
> > > > > pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
> > > > > ("ppc/xive: Add support for the PC MMIOs").
> > > > >
> > > >
> > > > Hi Cedric,
> > > >
> > > > While I am working with XIVE engineers to get the pnv_xive2_get_remote()
> > > > reworked as suggested (since it's a bit more work due to multiple cases
> > > > of indirect/direct vst, nvg/nvc types in case of XIVE2), I would like
> > > > to propose below patch to have as an interim solution to unblock
> > > > the PowerNV11 support patches.
> > >
> > > pHyp is an unknown FW implementation for opensource. Until an image
> > > is released somewhere (please think about it), QEMU has nothing to
> > > worry about other than supporting OPAL.
> > >
> > > For now, let's forget about the grouping aspect of XIVE2, simply
> > > rework pnv_xive2_get_remote() as it was done in b68147b7a5bf for
> > > XIVE. This shouldn't take long. And, for the nvg/nvc types, report
> > > an error of some sort and add a TODO in the code.
> > >
> > A similar change cannot be done to XIVE2, because Fredric’s commit (96a2132ce95) has introduced modifications to the NVPG and NVC MMIO callbacks in order to support backlog counter operations.
>
> Thanks for looking.
>
> Indeed. So I guess Aditya's proposal adding a new PnvChipClass handler
> is then the best alternative :
>
> @@ -170,6 +170,7 @@ struct PnvChipClass {
> void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
> void (*intc_destroy)(PnvChip *chip, PowerPCCPU *cpu);
> void (*intc_print_info)(PnvChip *chip, PowerPCCPU *cpu, GString *buf);
> + void* (*intc_get)(PnvChip *chip);
> ISABus *(*isa_create)(PnvChip *chip, Error **errp);
> void (*dt_populate)(PnvChip *chip, void *fdt);
> void (*pic_print_info)(PnvChip *chip, GString *buf);
>
> Aditya,
>
> Could you please resend the whole powernv11 series including this
> new patch for xive2 ?
Sure, will post v10 today.
Thanks Cedric !
>
> Thanks,
>
> C.
>
>
>
On 25/08/10 02:46PM, Cédric Le Goater wrote:
> + Glenn
> + Gautam
>
> On 8/10/25 12:45, Aditya Gupta wrote:
> > On 25/08/10 12:26PM, Aditya Gupta wrote:
> > > > <...snip...>
> > >
> > > About the error, seems xive2 always expecting powernv10 chip, I will
> > > have to rethink how should I use the same xive2 for powernv11.
> > >
> >
> > There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
> > The cast is only temporarily used to get the 'PnvXive2' object in the
> > Pnv10Chip.
> > It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
> >
> > Thinking to have a helper function to just return the 'PnvXive2' object
> > inside the chip, given a 'PnvChip'.
> >
> > Or the below change where we are adding another pointer in PnvChipClass:
> >
> > diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
> > index e019cad5c14c..9832be5fd297 100644
> > --- a/hw/intc/pnv_xive2.c
> > +++ b/hw/intc/pnv_xive2.c
> > @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
> > int i;
> > for (i = 0; i < pnv->num_chips; i++) {
> > - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
> > - PnvXive2 *xive = &chip10->xive;
> > + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
> > + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
> > /*
> > * Is this the XIVE matching the forwarded VSD address is for this
> >
> > Which one do you suggest ? Or should I look for another way ?
> >
> > I am preferring the first way to have a helper, but both ways look hacky.
>
> Any call to qdev_get_machine() in device model is at best
> a modeling shortcut, most likely it is a hack :
>
> /*
> * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
> * scan of all the chips INT controller is good enough.
> */
>
> So all these calls are suspicious :
>
> $ git grep qdev_get_machine hw/*/*pnv*
> hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>
> In the particular case of XIVE2, the solution is to rework
> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
> ("ppc/xive: Add support for the PC MMIOs").
I am having difficulties making a change here, don't know this path.
Going through the docs to understand XIVE2.
Will post once I have a patch.
Thanks Cedric,
- Aditya G
+ Mike Kowal
On Sun, 2025-08-10 at 14:46 +0200, Cédric Le Goater wrote:
> + Glenn
> + Gautam
>
> On 8/10/25 12:45, Aditya Gupta wrote:
> > On 25/08/10 12:26PM, Aditya Gupta wrote:
> > > > <...snip...>
> > >
> > > About the error, seems xive2 always expecting powernv10 chip, I will
> > > have to rethink how should I use the same xive2 for powernv11.
> > >
> >
> > There's a type cast to Pnv10Chip in 'pnv_xive2_get_remote'.
> > The cast is only temporarily used to get the 'PnvXive2' object in the
> > Pnv10Chip.
> > It's the only place in hw/intc/pnv_xive2.c assuming Pnv10Chip object.
> >
> > Thinking to have a helper function to just return the 'PnvXive2' object
> > inside the chip, given a 'PnvChip'.
> >
> > Or the below change where we are adding another pointer in PnvChipClass:
> >
> > diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
> > index e019cad5c14c..9832be5fd297 100644
> > --- a/hw/intc/pnv_xive2.c
> > +++ b/hw/intc/pnv_xive2.c
> > @@ -110,8 +110,8 @@ static PnvXive2 *pnv_xive2_get_remote(uint32_t vsd_type, hwaddr fwd_addr)
> > int i;
> >
> > for (i = 0; i < pnv->num_chips; i++) {
> > - Pnv10Chip *chip10 = PNV10_CHIP(pnv->chips[i]);
> > - PnvXive2 *xive = &chip10->xive;
> > + PnvChipClass *k = PNV_CHIP_GET_CLASS(pnv->chips[i]);
> > + PnvXive2 *xive = k->intc_get(pnv->chips[i]);
> >
> > /*
> > * Is this the XIVE matching the forwarded VSD address is for this
> >
> > Which one do you suggest ? Or should I look for another way ?
> >
> > I am preferring the first way to have a helper, but both ways look hacky.
>
> Any call to qdev_get_machine() in device model is at best
> a modeling shortcut, most likely it is a hack :
>
> /*
> * Remote access to INT controllers. HW uses MMIOs(?). For now, a simple
> * scan of all the chips INT controller is good enough.
> */
>
> So all these calls are suspicious :
>
> $ git grep qdev_get_machine hw/*/*pnv*
> hw/intc/pnv_xive2.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/pci-host/pnv_phb3.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_chiptod.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> hw/ppc/pnv_lpc.c: PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
>
> In the particular case of XIVE2, the solution is to rework
> pnv_xive2_get_remote() like it was for P9. See b68147b7a5bf
> ("ppc/xive: Add support for the PC MMIOs").
>
>
> Thanks,
>
> C.
>
>
>
>
>
>
>
© 2016 - 2025 Red Hat, Inc.