The Powernv11 machine doesn't have XIVE & PHBs as of now
XIVE2 interface and PHB5 added in later patches to Powernv11 machine
Also add mention of Power11 to powernv documentation
Cc: Cédric Le Goater <clg@kaod.org>
Cc: Frédéric Barrat <fbarrat@linux.ibm.com>
Cc: Mahesh J Salgaonkar <mahesh@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
---
docs/system/ppc/powernv.rst | 9 +++++----
hw/ppc/pnv.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/docs/system/ppc/powernv.rst b/docs/system/ppc/powernv.rst
index f3ec2cc69c0d..5154794cc8cd 100644
--- a/docs/system/ppc/powernv.rst
+++ b/docs/system/ppc/powernv.rst
@@ -1,5 +1,5 @@
-PowerNV family boards (``powernv8``, ``powernv9``, ``powernv10``)
-==================================================================
+PowerNV family boards (``powernv8``, ``powernv9``, ``powernv10``, ``powernv11``)
+================================================================================
PowerNV (as Non-Virtualized) is the "bare metal" platform using the
OPAL firmware. It runs Linux on IBM and OpenPOWER systems and it can
@@ -15,11 +15,12 @@ beyond the scope of what QEMU addresses today.
Supported devices
-----------------
- * Multi processor support for POWER8, POWER8NVL and POWER9.
+ * Multi processor support for POWER8, POWER8NVL, POWER9, Power10 and Power11.
* XSCOM, serial communication sideband bus to configure chiplets.
* Simple LPC Controller.
* Processor Service Interface (PSI) Controller.
- * Interrupt Controller, XICS (POWER8) and XIVE (POWER9) and XIVE2 (Power10).
+ * Interrupt Controller, XICS (POWER8) and XIVE (POWER9) and XIVE2 (Power10 &
+ Power11).
* POWER8 PHB3 PCIe Host bridge and POWER9 PHB4 PCIe Host bridge.
* Simple OCC is an on-chip micro-controller used for power management tasks.
* iBT device to handle BMC communication, with the internal BMC simulator
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 006ff62efd79..3e63b2891279 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -3145,6 +3145,37 @@ static void pnv_machine_p10_rainier_class_init(ObjectClass *oc, void *data)
pmc->i2c_init = pnv_rainier_i2c_init;
}
+static void pnv_machine_power11_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+ PnvMachineClass *pmc = PNV_MACHINE_CLASS(oc);
+ static const char compat[] = "qemu,powernv11\0ibm,powernv";
+
+ pmc->compat = compat;
+ pmc->compat_size = sizeof(compat);
+ pmc->max_smt_threads = 4;
+ pmc->has_lpar_per_thread = true;
+ pmc->quirk_tb_big_core = true;
+ pmc->dt_power_mgt = pnv_dt_power_mgt;
+
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
+
+ mc->desc = "IBM PowerNV (Non-Virtualized) Power11";
+ mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power11_v2.0");
+
+ object_class_property_add_bool(oc, "big-core",
+ pnv_machine_get_big_core,
+ pnv_machine_set_big_core);
+ object_class_property_set_description(oc, "big-core",
+ "Use big-core (aka fused-core) mode");
+
+ object_class_property_add_bool(oc, "lpar-per-core",
+ pnv_machine_get_lpar_per_core,
+ pnv_machine_set_lpar_per_core);
+ object_class_property_set_description(oc, "lpar-per-core",
+ "Use 1 LPAR per core mode");
+}
+
static void pnv_cpu_do_nmi_on_cpu(CPUState *cs, run_on_cpu_data arg)
{
CPUPPCState *env = cpu_env(cs);
@@ -3258,6 +3289,11 @@ static void pnv_machine_class_init(ObjectClass *oc, void *data)
}
static const TypeInfo types[] = {
+ {
+ .name = MACHINE_TYPE_NAME("powernv11"),
+ .parent = TYPE_PNV_MACHINE,
+ .class_init = pnv_machine_power11_class_init,
+ },
{
.name = MACHINE_TYPE_NAME("powernv10-rainier"),
.parent = MACHINE_TYPE_NAME("powernv10"),
--
2.49.0
On 3/25/25 12:23, Aditya Gupta wrote:
> The Powernv11 machine doesn't have XIVE & PHBs as of now
>
> XIVE2 interface and PHB5 added in later patches to Powernv11 machine
>
> Also add mention of Power11 to powernv documentation
>
> Cc: Cédric Le Goater <clg@kaod.org>
> Cc: Frédéric Barrat <fbarrat@linux.ibm.com>
> Cc: Mahesh J Salgaonkar <mahesh@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
> ---
> docs/system/ppc/powernv.rst | 9 +++++----
> hw/ppc/pnv.c | 36 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/docs/system/ppc/powernv.rst b/docs/system/ppc/powernv.rst
> index f3ec2cc69c0d..5154794cc8cd 100644
> --- a/docs/system/ppc/powernv.rst
> +++ b/docs/system/ppc/powernv.rst
> @@ -1,5 +1,5 @@
> -PowerNV family boards (``powernv8``, ``powernv9``, ``powernv10``)
> -==================================================================
> +PowerNV family boards (``powernv8``, ``powernv9``, ``powernv10``, ``powernv11``)
> +================================================================================
>
> PowerNV (as Non-Virtualized) is the "bare metal" platform using the
> OPAL firmware. It runs Linux on IBM and OpenPOWER systems and it can
> @@ -15,11 +15,12 @@ beyond the scope of what QEMU addresses today.
> Supported devices
> -----------------
>
> - * Multi processor support for POWER8, POWER8NVL and POWER9.
> + * Multi processor support for POWER8, POWER8NVL, POWER9, Power10 and Power11.
> * XSCOM, serial communication sideband bus to configure chiplets.
> * Simple LPC Controller.
> * Processor Service Interface (PSI) Controller.
> - * Interrupt Controller, XICS (POWER8) and XIVE (POWER9) and XIVE2 (Power10).
> + * Interrupt Controller, XICS (POWER8) and XIVE (POWER9) and XIVE2 (Power10 &
> + Power11).
> * POWER8 PHB3 PCIe Host bridge and POWER9 PHB4 PCIe Host bridge.
> * Simple OCC is an on-chip micro-controller used for power management tasks.
> * iBT device to handle BMC communication, with the internal BMC simulator
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 006ff62efd79..3e63b2891279 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -3145,6 +3145,37 @@ static void pnv_machine_p10_rainier_class_init(ObjectClass *oc, void *data)
> pmc->i2c_init = pnv_rainier_i2c_init;
> }
>
> +static void pnv_machine_power11_class_init(ObjectClass *oc, void *data)
> +{
> + MachineClass *mc = MACHINE_CLASS(oc);
> + PnvMachineClass *pmc = PNV_MACHINE_CLASS(oc);
> + static const char compat[] = "qemu,powernv11\0ibm,powernv";
> +
> + pmc->compat = compat;
> + pmc->compat_size = sizeof(compat);
> + pmc->max_smt_threads = 4;
> + pmc->has_lpar_per_thread = true;
> + pmc->quirk_tb_big_core = true;
> + pmc->dt_power_mgt = pnv_dt_power_mgt;
> +
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
There was a lot of work done to have dynamic PHBs in the PowerNV
machines. This was to add support in libvirt and this goal was
abandoned when people left. I think we should consider removing
it as it adds unnecessary complexity.
Anyhow,
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Thanks,
C.
+
> + mc->desc = "IBM PowerNV (Non-Virtualized) Power11";
> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power11_v2.0");
> +
> + object_class_property_add_bool(oc, "big-core",
> + pnv_machine_get_big_core,
> + pnv_machine_set_big_core);
> + object_class_property_set_description(oc, "big-core",
> + "Use big-core (aka fused-core) mode");
> +
> + object_class_property_add_bool(oc, "lpar-per-core",
> + pnv_machine_get_lpar_per_core,
> + pnv_machine_set_lpar_per_core);
> + object_class_property_set_description(oc, "lpar-per-core",
> + "Use 1 LPAR per core mode");
> +}
> +
> static void pnv_cpu_do_nmi_on_cpu(CPUState *cs, run_on_cpu_data arg)
> {
> CPUPPCState *env = cpu_env(cs);
> @@ -3258,6 +3289,11 @@ static void pnv_machine_class_init(ObjectClass *oc, void *data)
> }
>
> static const TypeInfo types[] = {
> + {
> + .name = MACHINE_TYPE_NAME("powernv11"),
> + .parent = TYPE_PNV_MACHINE,
> + .class_init = pnv_machine_power11_class_init,
> + },
> {
> .name = MACHINE_TYPE_NAME("powernv10-rainier"),
> .parent = MACHINE_TYPE_NAME("powernv10"),
On 25/03/25 20:17, Cédric Le Goater wrote:
> On 3/25/25 12:23, Aditya Gupta wrote:
>> <...snip...>
>>
>> +static void pnv_machine_power11_class_init(ObjectClass *oc, void
>> *data)
>> +{
>> + MachineClass *mc = MACHINE_CLASS(oc);
>> + PnvMachineClass *pmc = PNV_MACHINE_CLASS(oc);
>> + static const char compat[] = "qemu,powernv11\0ibm,powernv";
>> +
>> + pmc->compat = compat;
>> + pmc->compat_size = sizeof(compat);
>> + pmc->max_smt_threads = 4;
>> + pmc->has_lpar_per_thread = true;
>> + pmc->quirk_tb_big_core = true;
>> + pmc->dt_power_mgt = pnv_dt_power_mgt;
>> +
>> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
>
> There was a lot of work done to have dynamic PHBs in the PowerNV
> machines. This was to add support in libvirt and this goal was
> abandoned when people left. I think we should consider removing
> it as it adds unnecessary complexity.
>
Thanks for telling the history behind it, agreed this is unnecessary,
will remove in v7.
> Anyhow,
>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
>
Thanks for the tag Cédric !
- Aditya Gupta
> Thanks,
>
> C.
>
On 3/25/25 18:07, Aditya Gupta wrote:
> On 25/03/25 20:17, Cédric Le Goater wrote:
>
>> On 3/25/25 12:23, Aditya Gupta wrote:
>>> <...snip...>
>>>
>>> +static void pnv_machine_power11_class_init(ObjectClass *oc, void *data)
>>> +{
>>> + MachineClass *mc = MACHINE_CLASS(oc);
>>> + PnvMachineClass *pmc = PNV_MACHINE_CLASS(oc);
>>> + static const char compat[] = "qemu,powernv11\0ibm,powernv";
>>> +
>>> + pmc->compat = compat;
>>> + pmc->compat_size = sizeof(compat);
>>> + pmc->max_smt_threads = 4;
>>> + pmc->has_lpar_per_thread = true;
>>> + pmc->quirk_tb_big_core = true;
>>> + pmc->dt_power_mgt = pnv_dt_power_mgt;
>>> +
>>> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB);
>>
>> There was a lot of work done to have dynamic PHBs in the PowerNV
>> machines. This was to add support in libvirt and this goal was
>> abandoned when people left. I think we should consider removing
>> it as it adds unnecessary complexity.
>>
> Thanks for telling the history behind it, agreed this is unnecessary,
> will remove in v7.
One nice about it IIRC was being able to tune the number of
PHBs per chip, which reduced booting time (for 16s) and also
provided support to test various chip configs. Check that first.
Also, you should add functional tests for the powernv11 machine.
See under tests/functional/test_ppc64_powernv.py.
Thanks,
C.
On 25/03/25 22:45, Cédric Le Goater wrote: > On 3/25/25 18:07, Aditya Gupta wrote: >> On 25/03/25 20:17, Cédric Le Goater wrote: >> >>> On 3/25/25 12:23, Aditya Gupta wrote: >>>> <...snip...> >>>> >>>> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB); >>> >>> There was a lot of work done to have dynamic PHBs in the PowerNV >>> machines. This was to add support in libvirt and this goal was >>> abandoned when people left. I think we should consider removing >>> it as it adds unnecessary complexity. >>> >> Thanks for telling the history behind it, agreed this is unnecessary, >> will remove in v7. > > One nice about it IIRC was being able to tune the number of > PHBs per chip, which reduced booting time (for 16s) and also > provided support to test various chip configs. Check that first. > I tried some variations of 'device_add/device_del'. Unable to see how to dynamically add/remove phbs. Do you have any options to device_add/del which I can try, I want to see if the dynamic addition/removal of PHB changes if i remove that '_allow_dynamic_sysbus_dev' call. > Also, you should add functional tests for the powernv11 machine. > > See under tests/functional/test_ppc64_powernv.py. > Currently the test uses op-build kernels, which don't support Power11, working on that side, will post as soon as op-build creates a new release with p11 support (any linux >= 6.9). Thanks, - Aditya Gupta > > Thanks, > > C. >
On 3/25/25 18:38, Aditya Gupta wrote: > On 25/03/25 22:45, Cédric Le Goater wrote: > >> On 3/25/25 18:07, Aditya Gupta wrote: >>> On 25/03/25 20:17, Cédric Le Goater wrote: >>> >>>> On 3/25/25 12:23, Aditya Gupta wrote: >>>>> <...snip...> >>>>> >>>>> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_PNV_PHB); >>>> >>>> There was a lot of work done to have dynamic PHBs in the PowerNV >>>> machines. This was to add support in libvirt and this goal was >>>> abandoned when people left. I think we should consider removing >>>> it as it adds unnecessary complexity. >>>> >>> Thanks for telling the history behind it, agreed this is unnecessary, will remove in v7. >> >> One nice about it IIRC was being able to tune the number of >> PHBs per chip, which reduced booting time (for 16s) and also >> provided support to test various chip configs. Check that first. >> > I tried some variations of 'device_add/device_del'. Unable to see how to dynamically add/remove phbs. I don't think hotplug works, this would require FW support, only coldplug is supported : devices should be defined on the command line. > > Do you have any options to device_add/del which I can try, I want to see if the dynamic addition/removal of PHB changes if i remove that '_allow_dynamic_sysbus_dev' call. > > >> Also, you should add functional tests for the powernv11 machine. >> >> See under tests/functional/test_ppc64_powernv.py. >> > Currently the test uses op-build kernels, which don't support Power11, working on that side, will post as soon as op-build creates a new release with p11 support (any linux >= 6.9). And is that planned ? I doubt it since open-power boxes are out of business. You could use a buildroot image instead. : https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig Thanks, C.
On 26/03/25 13:39, Cédric Le Goater wrote:
> On 3/25/25 18:38, Aditya Gupta wrote:
>> <...snip...>
>>
>> On 25/03/25 22:45, Cédric Le Goater wrote:
>>> One nice about it IIRC was being able to tune the number of
>>> PHBs per chip, which reduced booting time (for 16s) and also
>>> provided support to test various chip configs. Check that first.
>>>
>> I tried some variations of 'device_add/device_del'. Unable to see how
>> to dynamically add/remove phbs.
>
> I don't think hotplug works, this would require FW support, only
> coldplug is supported : devices should be defined on the command
> line.
Got it. Thanks for mentioning this, found a bug in my patch:
$ ./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults
-serial mon:stdio -device pnv-phb -device pnv-phb-root-port
<$QEMU_DIR>/include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object
0x564afddb5e00 is not an instance of type pnv10-chip
[1] 1253963 IOT instruction (core dumped)
./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial
-devic
Happens due to 'pnv_pec_add_phb' assuming phb5 to be related to pnv10:
if (phb->version == 4) {
Pnv9Chip *chip9 = PNV9_CHIP(chip);
pecs = chip9->pecs;
} else if (phb->version == 5) {
Pnv10Chip *chip10 = PNV10_CHIP(chip);
pecs = chip10->pecs;
}
Top of my mind, hacky ways come up to differentiate Pnv11Chip and
Pnv10Chip, other (still hacky) might be to add "pecs" as a property to
the chip objects and get it that way, still feels hacky.
Can't pass extra args (pecs) to the function, without handling this
pnv10 vs pnv11 in the callers.
Is adding a callback to PnvChipClass->get_pecs a good idea, similar to
xive callbacks on the chipclass ?
Will think of alternate ways. Thanks.
>
>>
>> Do you have any options to device_add/del which I can try, I want to
>> see if the dynamic addition/removal of PHB changes if i remove that
>> '_allow_dynamic_sysbus_dev' call.
>>
>>
>>> Also, you should add functional tests for the powernv11 machine.
>>>
>>> See under tests/functional/test_ppc64_powernv.py.
>>>
>> Currently the test uses op-build kernels, which don't support
>> Power11, working on that side, will post as soon as op-build creates
>> a new release with p11 support (any linux >= 6.9).
>
> And is that planned ? I doubt it since open-power boxes are out
> of business.
>
> You could use a buildroot image instead. :
>
> https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig
>
I was thinking there should be. I will ask.
Thanks,
- Aditya Gupta
> Thanks,
>
> C.
>
On 3/26/25 18:21, Aditya Gupta wrote:
> On 26/03/25 13:39, Cédric Le Goater wrote:
>
>> On 3/25/25 18:38, Aditya Gupta wrote:
>>> <...snip...>
>>>
>>> On 25/03/25 22:45, Cédric Le Goater wrote:
>>>> One nice about it IIRC was being able to tune the number of
>>>> PHBs per chip, which reduced booting time (for 16s) and also
>>>> provided support to test various chip configs. Check that first.
>>>>
>>> I tried some variations of 'device_add/device_del'. Unable to see how to dynamically add/remove phbs.
>>
>> I don't think hotplug works, this would require FW support, only
>> coldplug is supported : devices should be defined on the command
>> line.
>
>
> Got it. Thanks for mentioning this, found a bug in my patch:
>
>
> $ ./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial mon:stdio -device pnv-phb -device pnv-phb-root-port
> <$QEMU_DIR>/include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object 0x564afddb5e00 is not an instance of type pnv10-chip
> [1] 1253963 IOT instruction (core dumped) ./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial -devic
>
> Happens due to 'pnv_pec_add_phb' assuming phb5 to be related to pnv10:
>
>
> if (phb->version == 4) {
> Pnv9Chip *chip9 = PNV9_CHIP(chip);
>
> pecs = chip9->pecs;
> } else if (phb->version == 5) {
> Pnv10Chip *chip10 = PNV10_CHIP(chip);
>
> pecs = chip10->pecs;
> }
>
>
> Top of my mind, hacky ways come up to differentiate Pnv11Chip and Pnv10Chip, other (still hacky) might be to add "pecs" as a property to the chip objects and get it that way, still feels hacky.
>
The pnv-phb and pnv-phb-root-port devices introduced too much
complexity for an unused feature. It is time to step back and
deprecate.
The segfault on P11 should be fixed. Failing gracefully is OK.
Thanks,
C.
> Can't pass extra args (pecs) to the function, without handling this pnv10 vs pnv11 in the callers.
>
>
> Is adding a callback to PnvChipClass->get_pecs a good idea, similar to xive callbacks on the chipclass ?
>
> Will think of alternate ways. Thanks.
>
>
>>
>>>
>>> Do you have any options to device_add/del which I can try, I want to see if the dynamic addition/removal of PHB changes if i remove that '_allow_dynamic_sysbus_dev' call.
>>>
>>>
>>>> Also, you should add functional tests for the powernv11 machine.
>>>>
>>>> See under tests/functional/test_ppc64_powernv.py.
>>>>
>>> Currently the test uses op-build kernels, which don't support Power11, working on that side, will post as soon as op-build creates a new release with p11 support (any linux >= 6.9).
>>
>> And is that planned ? I doubt it since open-power boxes are out
>> of business.
>>
>> You could use a buildroot image instead. :
>>
>> https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig
>>
> I was thinking there should be. I will ask.
>
>
> Thanks,
>
> - Aditya Gupta
>
>> Thanks,
>>
>> C.
>>
On 25/03/26 11:09PM, Cédric Le Goater wrote:
> On 3/26/25 18:21, Aditya Gupta wrote:
> > On 26/03/25 13:39, Cédric Le Goater wrote:
> >
> > > On 3/25/25 18:38, Aditya Gupta wrote:
> > > > <...snip...>
> > > >
> > > > On 25/03/25 22:45, Cédric Le Goater wrote:
> > > > > One nice about it IIRC was being able to tune the number of
> > > > > PHBs per chip, which reduced booting time (for 16s) and also
> > > > > provided support to test various chip configs. Check that first.
> > > > >
> > > > I tried some variations of 'device_add/device_del'. Unable to see how to dynamically add/remove phbs.
> > >
> > > I don't think hotplug works, this would require FW support, only
> > > coldplug is supported : devices should be defined on the command
> > > line.
> >
> >
> > Got it. Thanks for mentioning this, found a bug in my patch:
> >
> >
> > $ ./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial mon:stdio -device pnv-phb -device pnv-phb-root-port
> > <$QEMU_DIR>/include/hw/ppc/pnv_chip.h:110:PNV10_CHIP: Object 0x564afddb5e00 is not an instance of type pnv10-chip
> > [1] 1253963 IOT instruction (core dumped) ./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial -devic
> >
> > Happens due to 'pnv_pec_add_phb' assuming phb5 to be related to pnv10:
> >
> >
> > if (phb->version == 4) {
> > Pnv9Chip *chip9 = PNV9_CHIP(chip);
> >
> > pecs = chip9->pecs;
> > } else if (phb->version == 5) {
> > Pnv10Chip *chip10 = PNV10_CHIP(chip);
> >
> > pecs = chip10->pecs;
> > }
> >
> >
> > Top of my mind, hacky ways come up to differentiate Pnv11Chip and Pnv10Chip, other (still hacky) might be to add "pecs" as a property to the chip objects and get it that way, still feels hacky.
> >
>
> The pnv-phb and pnv-phb-root-port devices introduced too much
> complexity for an unused feature. It is time to step back and
> deprecate.
>
> The segfault on P11 should be fixed. Failing gracefully is OK.
Sure Cedric, for now I have removed the dynamic phbs in powernv11, so it
fails like this:
./build/qemu-system-ppc64 -nographic -M powernv11 -nodefaults -serial mon:stdio -device pnv-phb -device pnv-phb-root-port
qemu-system-ppc64: -device pnv-phb: Parameter 'driver' expects a dynamic sysbus device type for the machine
Regarding deprecating for p10, don't know, as you said it gave benefits
in power10 bringup, maybe since it's working for power10 it might keep
it. I haven't personally needed it though.
Thanks,
- Aditya Gupta
>
> Thanks,
>
> C.
>
>
>
>
>
> > Can't pass extra args (pecs) to the function, without handling this pnv10 vs pnv11 in the callers.
> >
> >
> > Is adding a callback to PnvChipClass->get_pecs a good idea, similar to xive callbacks on the chipclass ?
> >
> > Will think of alternate ways. Thanks.
> >
> >
> > >
> > > >
> > > > Do you have any options to device_add/del which I can try, I want to see if the dynamic addition/removal of PHB changes if i remove that '_allow_dynamic_sysbus_dev' call.
> > > >
> > > >
> > > > > Also, you should add functional tests for the powernv11 machine.
> > > > >
> > > > > See under tests/functional/test_ppc64_powernv.py.
> > > > >
> > > > Currently the test uses op-build kernels, which don't support Power11, working on that side, will post as soon as op-build creates a new release with p11 support (any linux >= 6.9).
> > >
> > > And is that planned ? I doubt it since open-power boxes are out
> > > of business.
> > >
> > > You could use a buildroot image instead. :
> > >
> > > https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig
> > >
> > I was thinking there should be. I will ask.
> >
> >
> > Thanks,
> >
> > - Aditya Gupta
> >
> > > Thanks,
> > >
> > > C.
> > >
>
[ ... ]
> You could use a buildroot image instead. :
>
> https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig
Images pushed here :
https://github.com/legoater/qemu-ppc-boot/tree/main/buildroot/qemu_ppc64le_powernv8-2025.02
qemu-system-ppc64 -m 1G -M powernv10 \
-kernel ./buildroot/qemu_ppc64le_powernv8-2025.02/vmlinux \
-append root=/dev/nvme0n1 \
-device nvme,bus=pcie.2,addr=0x0,drive=drive0,serial=1234 \
-drive file=./buildroot/qemu_ppc64le_powernv8-2025.02/rootfs.ext2,if=none,id=drive0,format=raw,cache=none \
-device e1000e,bus=pcie.1,addr=0x0,netdev=net0 \
-netdev user,id=net0 \
-serial mon:stdio -nographic -snapshot
[ 0.010515922,5] OPAL v7.1-106-g785a5e307 starting...
...
[ 0.000000][ T0] Linux version 6.12.9 (legoater@ryzen) (powerpc64le-buildroot-linux-gnu-gcc.br_real (Buildroot 2025.02) 13.3.0, GNU ld (GNU Binutils) 2.43.1) #1 SMP Wed Mar 26 11:11:35 CET 2025
...
Please use these images or the opbuild image which should also work but
the CPU won't be recognized as a POWER11.
Thanks,
C.
On 26/03/25 16:12, Cédric Le Goater wrote: > [ ... ] > >> You could use a buildroot image instead. : >> >> https://github.com/buildroot/buildroot/blob/master/configs/qemu_ppc64le_powernv8_defconfig > > Images pushed here : > > https://github.com/legoater/qemu-ppc-boot/tree/main/buildroot/qemu_ppc64le_powernv8-2025.02 > > qemu-system-ppc64 -m 1G -M powernv10 \ > -kernel ./buildroot/qemu_ppc64le_powernv8-2025.02/vmlinux \ > -append root=/dev/nvme0n1 \ > -device nvme,bus=pcie.2,addr=0x0,drive=drive0,serial=1234 \ > -drive > file=./buildroot/qemu_ppc64le_powernv8-2025.02/rootfs.ext2,if=none,id=drive0,format=raw,cache=none > \ > -device e1000e,bus=pcie.1,addr=0x0,netdev=net0 \ > -netdev user,id=net0 \ > -serial mon:stdio -nographic -snapshot > > [ 0.010515922,5] OPAL v7.1-106-g785a5e307 starting... > ... > [ 0.000000][ T0] Linux version 6.12.9 (legoater@ryzen) > (powerpc64le-buildroot-linux-gnu-gcc.br_real (Buildroot 2025.02) > 13.3.0, GNU ld (GNU Binutils) 2.43.1) #1 SMP Wed Mar 26 11:11:35 CET 2025 > ... > > Please use these images or the opbuild image which should also work but > the CPU won't be recognized as a POWER11. Thank you, will use those images then. opbuild image boots but since it doesn't "print" p11 in its dmesg log, the powernv test fails with it. Will use your images. Thanks, - Aditya Gupta > > Thanks, > > C. >
© 2016 - 2025 Red Hat, Inc.