hw/pci-host: Update PHB5 XSCOM registers

Add new XSCOM registers introduced in PHB5.
Apply bit-masks within xscom-write methods.
Bit-masks specified using PPC_BITMASK macro.

Signed-off-by: Saif Abr

hw/pci-host: Update PHB5 XSCOM registers

Add new XSCOM registers introduced in PHB5.
Apply bit-masks within xscom-write methods.
Bit-masks specified using PPC_BITMASK macro.

Signed-off-by: Saif Abrar <saif.abrar@linux.vnet.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Message-ID: <20231016175948.10869-1-saif.abrar@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

pnv_phb4_pec: Simplify/align code to parent user-created PHBs

When instantiating a user-created PHB on P9/P10, we don't really have
a reason any more to go through an indirection in pnv_chip_add_phb

pnv_phb4_pec: Simplify/align code to parent user-created PHBs

When instantiating a user-created PHB on P9/P10, we don't really have
a reason any more to go through an indirection in pnv_chip_add_phb()
in pnv.c, we can go straight to the right function in
pnv_phb4_pec.c. That way, default PHBs and user-created PHBs are all
handled in the same file. This patch also renames pnv_phb4_get_pec()
to pnv_pec_add_phb() to better reflect that it "hooks" a PHB to a PEC.

For P8, the PHBs are parented to the chip directly, so it makes sense
to keep calling pnv_chip_add_phb() in pnv.c, to also be consistent
with where default PHBs are handled. The only change here is that,
since that function is now only used for P8, we can refine the return
type.

So overall, the PnvPHB front-end now has a pnv_phb_user_get_parent()
function which handles the parenting of the user-created PHBs by
calling the right function in the right file based on the processor
version. It's also easily extensible if we ever need to support a
different parent object.

Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20230302163715.129635-5-fbarrat@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

pnv_phb4_pec: Move pnv_phb4_get_pec() to rightful file

The function pnv_phb4_get_pec() exposes some internals of the PEC and
PHB logic, yet it was in the higher level hw/ppc/pnv.c file for
historica

pnv_phb4_pec: Move pnv_phb4_get_pec() to rightful file

The function pnv_phb4_get_pec() exposes some internals of the PEC and
PHB logic, yet it was in the higher level hw/ppc/pnv.c file for
historical reasons: P8 implements the PHBs from pnv.c directly, but on
P9/P10, it's done through the CEC model, which has its own file. So
move pnv_phb4_get_pec() to hw/pci-host/pnv_phb4_pec.c, where it fits
naturally.

While at it, replace the PnvPHB4 parameter by the PnvPHB front-end,
since it has all the information needed and simplify it a bit.

No functional changes.

Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20230302163715.129635-4-fbarrat@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

pnv_phb4_pec: Only export existing PHBs to the device tree

So far, we were always exporting all possible PHBs to the device
tree. It works well when using the default config but it potentially
adds

pnv_phb4_pec: Only export existing PHBs to the device tree

So far, we were always exporting all possible PHBs to the device
tree. It works well when using the default config but it potentially
adds non-existing devices when using '-nodefaults' and user-created
PHBs, causing the firmware (skiboot) to report errors when probing
those PHBs. This patch only exports PHBs which have been realized to
the device tree.

Fixes: d786be3fe746 ("ppc/pnv: enable user created pnv-phb for powernv9")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20230302163715.129635-3-fbarrat@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

pnv_phb4_pec: Keep track of instantiated PHBs

Add an array on the PEC object to keep track of the PHBs which are
instantiated. The array can be sparsely populated when using
user-created PHBs. It wi

pnv_phb4_pec: Keep track of instantiated PHBs

Add an array on the PEC object to keep track of the PHBs which are
instantiated. The array can be sparsely populated when using
user-created PHBs. It will be useful for the next patch to only export
instantiated PHBs in the device tree.

Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20230302163715.129635-2-fbarrat@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

include/hw/ppc: Split pnv_chip.h off pnv.h

PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip are defined
in pnv.h. Many users of the header don't actually need them. One
instance is this in

include/hw/ppc: Split pnv_chip.h off pnv.h

PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip are defined
in pnv.h. Many users of the header don't actually need them. One
instance is this inclusion loop: hw/ppc/pnv_homer.h includes
hw/ppc/pnv.h for typedef PnvChip, and vice versa for struct PnvHomer.

Similar structs live in their own headers: PnvHomerClass and PnvHomer
in pnv_homer.h, PnvLpcClass and PnvLpcController in pci_lpc.h,
PnvPsiClass, PnvPsi, Pnv8Psi, Pnv9Psi, Pnv10Psi in pnv_psi.h, ...

Move PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip to new
pnv_chip.h, and adjust include directives. This breaks the inclusion
loop mentioned above.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20221222104628.659681-2-armbru@redhat.com>

show more ...

ppc/pnv: enable user created pnv-phb for powernv9

Enable pnv-phb user created devices for powernv9 now that we have
everything in place.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by:

ppc/pnv: enable user created pnv-phb for powernv9

Enable pnv-phb user created devices for powernv9 now that we have
everything in place.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220811163950.578927-9-danielhb413@gmail.com>

show more ...

ppc/pnv: remove pecc->rp_model

The attribute is unused.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <202206240849

ppc/pnv: remove pecc->rp_model

The attribute is unused.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220624084921.399219-11-danielhb413@gmail.com>

show more ...

ppc/pnv: remove pnv-phb4-root-port

The unified pnv-phb-root-port can be used instead. The phb4-root-port
device isn't exposed to the user in any official QEMU release so there's
no ABI breakage in r

ppc/pnv: remove pnv-phb4-root-port

The unified pnv-phb-root-port can be used instead. The phb4-root-port
device isn't exposed to the user in any official QEMU release so there's
no ABI breakage in removing it.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220624084921.399219-9-danielhb413@gmail.com>

show more ...

ppc/pnv: turn PnvPHB4 into a PnvPHB backend

Change the parent type of the PnvPHB4 device to TYPE_PARENT since the
PCI bus is going to be initialized by the PnvPHB parent. Functions that
needs to acc

ppc/pnv: turn PnvPHB4 into a PnvPHB backend

Change the parent type of the PnvPHB4 device to TYPE_PARENT since the
PCI bus is going to be initialized by the PnvPHB parent. Functions that
needs to access the bus via a PnvPHB4 object can do so via the
phb4->phb_base pointer.

pnv_phb4_pec now creates a PnvPHB object.

The powernv9 machine class will create PnvPHB devices with version '4'.
powernv10 will create using version '5'. Both are using global machine
properties in their class_init() to do that.

These changes will benefit us when adding PnvPHB user creatable devices
for powernv9 and powernv10.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-Id: <20220624084921.399219-6-danielhb413@gmail.com>

show more ...

ppc/pnv: move root port attach to pnv_phb4_realize()

Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.

Reviewed-by: Fr

ppc/pnv: move root port attach to pnv_phb4_realize()

Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.

Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220621173436.165912-2-danielhb413@gmail.com>

show more ...

ppc/pnv: fix extra indent spaces with DEFINE_PROP*

The DEFINE_PROP* macros in pnv files are using extra spaces for no good
reason.

Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by

ppc/pnv: fix extra indent spaces with DEFINE_PROP*

The DEFINE_PROP* macros in pnv files are using extra spaces for no good
reason.

Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20220602215351.149910-1-danielhb413@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

Remove qemu-common.h include from most units

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com>
Signed-off-by: Paolo B

Remove qemu-common.h include from most units

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

ppc/pnv: Remove user-created PHB{3,4,5} devices

On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out lik

ppc/pnv: Remove user-created PHB{3,4,5} devices

On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI adapter on a slot. Nevertheless, having user-created
PHBs in QEMU seemed to be a good idea for testing purposes :

1. having a limited set of PHBs speedups boot time.
2. it is useful to be able to mimic a partially broken topology you
some time have to deal with during bring-up.

PowerNV is also used for distro install tests and having libvirt
support eases these tasks. libvirt prefers to run the machine with
-nodefaults to be sure not to drag unexpected devices which would need
to be defined in the domain file without being specified on the QEMU
command line. For this reason :

3. -nodefaults should not include default PHBs

User-created PHB{3,4,5} devices satisfied all these needs but reality
proves to be a bit more complex, internally when modeling such
devices, and externally when dealing with the user interface.

Req 1. and 2. can be simply addressed differently with a machine option:
"phb-mask=<uint>", which QEMU would use to enable/disable PHB device
nodes when creating the device tree.

For Req 3., we need to make sure we are taking the right approach. It
seems that we should expose a new type of user-created PHB device, a
generic virtualized one, that libvirt would use and not one depending
on the processor revision. This needs more thinking.

For now, remove user-created PHB{3,4,5} devices. All the cleanups we
did are not lost and they will be useful for the next steps.

Fixes: 5bc67b052b51 ("ppc/pnv: Introduce user creatable pnv-phb4 devices")
Fixes: 1f6a88fffc75 ("ppc/pnv: Introduce support for user created PHB3 devices")
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220314130514.529931-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: Introduce a pnv-phb5 device to match root port

We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and
POWER9 respectively. POWER10 uses version 5 of the PHB. It is very
close to t

ppc/pnv: Introduce a pnv-phb5 device to match root port

We already have the pnv-phb3 and pnv-phb4 devices for POWER8 and
POWER9 respectively. POWER10 uses version 5 of the PHB. It is very
close to the PHB4 from POWER9, at least in our model and we could
almost keep using the PHB4 model. However the matching root port
pnv-phb5-root-port is specific to POWER10 so to avoid confusion as
well as making it easy to introduce differences later, we create a
pnv-phb5 class, which is mostly an alias for pnv-phb4 for now.

With this patch, the command line for a user-created PHB on powernv10
becomes:
-machine powernv10 -nodefaults -device pnv-phb5 -device pnv-phb5-root-port

Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220310155101.294568-2-fbarrat@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge

PHB4 and PHB5 are very similar. Use the PHB4 models with some minor
adjustements in a subclass for P10.

Signed-off-by: Cédric Le Goater <clg@kao

ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge

PHB4 and PHB5 are very similar. Use the PHB4 models with some minor
adjustements in a subclass for P10.

Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: Remove PHB4 version property

Grab the PHB version from the PEC class directly when needed.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@

ppc/pnv: Remove PHB4 version property

Grab the PHB version from the PEC class directly when needed.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220117122753.1655504-4-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: Add a 'rp_model' class attribute for the PHB4 PEC

PHB5 will introduce its own root port model. Prepare ground for it.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Hen

ppc/pnv: Add a 'rp_model' class attribute for the PHB4 PEC

PHB5 will introduce its own root port model. Prepare ground for it.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220117122753.1655504-3-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: Move root port allocation under pnv_pec_default_phb_realize()

The root port device is currently created and attached to the PHB
early in pnv_phb4_realize(). Do it under pnv_pec_default_phb_

ppc/pnv: Move root port allocation under pnv_pec_default_phb_realize()

The root port device is currently created and attached to the PHB
early in pnv_phb4_realize(). Do it under pnv_pec_default_phb_realize()
after the PHB is fully realized. It's cleaner and avoids an extra
test on defaults_enabled().

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220117122753.1655504-2-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: remove PnvPhb4PecStack object

All the complexity that was scattered between PnvPhb4PecStack and
PnvPHB4 are now centered in the PnvPHB4 device. PnvPhb4PecStack does not
serve any purpose in

ppc/pnv: remove PnvPhb4PecStack object

All the complexity that was scattered between PnvPhb4PecStack and
PnvPHB4 are now centered in the PnvPHB4 device. PnvPhb4PecStack does not
serve any purpose in the current code base.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220114180719.52117-8-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: make PECs create and realize PHB4s

This patch changes the design of the PEC device to create and realize PHB4s
instead of PecStacks. After all the recent changes, PHB4s now contain all
the

ppc/pnv: make PECs create and realize PHB4s

This patch changes the design of the PEC device to create and realize PHB4s
instead of PecStacks. After all the recent changes, PHB4s now contain all
the information needed for their proper functioning, not relying on PecStack
in any capacity.

All changes are being made in a single patch to avoid renaming parts of
the PecState and leaving the code in a strange way. E.g. rename
PecClass->num_stacks to num_phbs, which would then read a
pnv_pec_num_stacks[] array. To avoid mixing the old and new design more
than necessary it's clearer to do these changes in a single step.

The name changes made are:

- in PnvPhb4PecState:
* rename 'num_stacks' to 'num_phbs'
* remove the pec->stacks[] array. Current code relies on the
pec->stacks[] obj acting as a simple container, without ever accessing
pec->stacks[] for any other purpose. Instead of converting this into a
pec->phbs[] array, remove it

- in PnvPhb4PecClass, rename *num_stacks to *num_phbs;

- pnv_pec_num_stacks[] is renamed to pnv_pec_num_phbs[].

The logical changes:

- pnv_pec_default_phb_realize():
* init and set the properties of the PnvPHB4 qdev
* do not use stack->phb anymore;

- pnv_pec_realize():
* use the new default_phb_realize() to init/realize each PHB if
running with defaults;

- pnv_pec_instance_init(): removed since we're creating the PHBs during
pec_realize();

- pnv_phb4_get_stack():
* renamed to pnv_phb4_get_pec() and returns a PnvPhb4PecState*;

- pnv_phb4_realize(): use 'phb->pec' instead of 'stack'.

This design change shouldn't caused any behavioral change in the runtime
of the machine.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220114180719.52117-7-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: remove PnvPhb4PecStack::stack_no

pnv_pec_default_phb_realize() stopped using it after the previous patch and
no one else is using it.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gm

ppc/pnv: remove PnvPhb4PecStack::stack_no

pnv_pec_default_phb_realize() stopped using it after the previous patch and
no one else is using it.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220114180719.52117-6-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: move default_phb_realize() to pec_realize()

Move the current pnv_pec_stk_default_phb_realize() call to
pec_realize(), renaming the function to pnv_pec_default_phb_realize(),
and set the PHB

ppc/pnv: move default_phb_realize() to pec_realize()

Move the current pnv_pec_stk_default_phb_realize() call to
pec_realize(), renaming the function to pnv_pec_default_phb_realize(),
and set the PHB attributes using the PEC object directly.

This will be important to allow for PECs devices to handle PHB4s
directly later on.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220114180719.52117-5-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: remove stack pointer from PnvPHB4

This pointer was being used for two reasons: pnv_phb4_update_regions()
was using it to access the PHB and phb4_realize() was using it as a way
to determine

ppc/pnv: remove stack pointer from PnvPHB4

This pointer was being used for two reasons: pnv_phb4_update_regions()
was using it to access the PHB and phb4_realize() was using it as a way
to determine if the PHB was user created.

We can determine if the PHB is user created via phb->pec, introduced in
the previous patch, and pnv_phb4_update_regions() is no longer using
stack->phb.

Remove the pointer from the PnvPHB4 device.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220114180719.52117-4-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

ppc/pnv: introduce PnvPHB4 'pec' property

This property will track the owner PEC of this PHB. For now it's
redundant since we can retrieve the PEC via phb->stack->pec but it
will not be redundant wh

ppc/pnv: introduce PnvPHB4 'pec' property

This property will track the owner PEC of this PHB. For now it's
redundant since we can retrieve the PEC via phb->stack->pec but it
will not be redundant when we get rid of the stack device.

Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220114180719.52117-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...