#
277ee172 |
| 15-May-2023 |
Nicholas Piggin <npiggin@gmail.com> |
target/ppc: Add POWER9 DD2.2 model
POWER9 DD2.1 and earlier had significant limitations when running KVM, including lack of "mixed mode" MMU support (ability to run HPT and RPT mode on threads of th
target/ppc: Add POWER9 DD2.2 model
POWER9 DD2.1 and earlier had significant limitations when running KVM, including lack of "mixed mode" MMU support (ability to run HPT and RPT mode on threads of the same core), and a translation prefetch issue which is worked around by disabling "AIL" mode for the guest.
These processors are not widely available, and it's difficult to deal with all these quirks in qemu +/- KVM, so create a POWER9 DD2.2 CPU and make it the default POWER9 CPU.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Message-Id: <20230515160201.394587-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
Revision tags: v8.0.0 |
|
#
ddf0676f |
| 02-Mar-2023 |
Frederic Barrat <fbarrat@linux.ibm.com> |
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 ...
|
#
c0a5a477 |
| 22-Dec-2022 |
Markus Armbruster <armbru@redhat.com> |
include/hw/ppc: Don't include hw/pci-host/pnv_phb.h from pnv.h
The next commit needs to include hw/ppc/pnv.h from hw/pci-host/pnv_phb.h. Avoid an inclusion loop.
Signed-off-by: Markus Armbruster <
include/hw/ppc: Don't include hw/pci-host/pnv_phb.h from pnv.h
The next commit needs to include hw/ppc/pnv.h from hw/pci-host/pnv_phb.h. Avoid an inclusion loop.
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-4-armbru@redhat.com>
show more ...
|
#
2c6fe2e2 |
| 22-Dec-2022 |
Markus Armbruster <armbru@redhat.com> |
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 ...
|
Revision tags: v7.2.0 |
|
#
0d512c71 |
| 11-Aug-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: turn chip8->phbs[] into a PnvPHB* array
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different man
ppc/pnv: turn chip8->phbs[] into a PnvPHB* array
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different manners. The only difference between these PHBs is that one will have a valid phb3->chip that is assigned during pnv_chip_power8_realize(), while the user created needs to search which chip it belongs to.
Aside from that there shouldn't be any difference. Making the default PHBs behave in line with the user created ones will make it easier to re-introduce them later on. It will also make the code easier to follow since we are dealing with them in equal manner.
The first step is to turn chip8->phbs[] into a PnvPHB3 pointer array. This will allow us to assign user created PHBs into it later on. The way we initilize the default case is now more in line with that would happen with the user created case: the object is created, parented by the chip because pnv_xscom_dt() relies on it, and then assigned to the array.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-6-danielhb413@gmail.com>
show more ...
|
#
ba47c3a4 |
| 11-Aug-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: add helpers for pnv-phb user devices
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{
ppc/pnv: add helpers for pnv-phb user devices
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". They are needed to amend the QOM and bus hierarchies of user created pnv-phbs, matching them with default pnv-phbs.
A new helper pnv_phb_user_device_init() is created to handle user-created devices setup. We're going to call it inside pnv_phb_realize() in case we're realizing an user created device. This will centralize all user device realated in a single spot, leaving the realize functions of the phb3/phb4 backends untouched.
Another helper called pnv_chip_add_phb() was added to handle the particularities of each chip version when adding a new PHB.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-5-danielhb413@gmail.com>
show more ...
|
#
e5ea9436 |
| 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: move attach_root_port helper to pnv-phb.c
The helper is only used in this file.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.i
ppc/pnv: move attach_root_port helper to pnv-phb.c
The helper is only used in this file.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-13-danielhb413@gmail.com>
show more ...
|
#
17c681e9 |
| 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: remove root port name from pnv_phb_attach_root_port()
We support only a single root port, PNV_PHB_ROOT_PORT.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Fre
ppc/pnv: remove root port name from pnv_phb_attach_root_port()
We support only a single root port, PNV_PHB_ROOT_PORT.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-10-danielhb413@gmail.com>
show more ...
|
#
1f5d6b2a |
| 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: turn PnvPHB3 into a PnvPHB backend
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend.
In the PnvPHB3, since the PnvPHB device imple
ppc/pnv: turn PnvPHB3 into a PnvPHB backend
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend.
In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bus, change PnvPHB3 parent to TYPE_DEVICE. There are a couple of instances in pnv_phb3.c that needs to access the PCI bus, so a phb_base pointer is added to allow access to the parent PnvPHB. The PnvPHB3 root port will now be connected to a PnvPHB object.
In pnv.c, the powernv8 machine chip8 will now hold an array of PnvPHB objects. pnv_get_phb3_child() needs to be adapted to return the PnvPHB3 backend from the PnvPHB child. A global property is added in pnv_machine_power8_class_init() to ensure that all PnvPHBs are created with phb->version = 3.
After all these changes we're still able to boot a powernv8 machine with default settings. The real gain will come with user created PnvPHB devices, coming up next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-4-danielhb413@gmail.com>
show more ...
|
#
0bf4d77e |
| 11-Aug-2022 |
Nicholas Piggin <npiggin@gmail.com> |
ppc/pnv: Add initial P9/10 SBE model
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register a
ppc/pnv: Add initial P9/10 SBE model
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register access, MPIPL). The latter facilities are accessed mostly via a message system called SBEFIFO.
This driver provides initial emulation for the SBE runtime registers and a very basic SBEFIFO implementation that provides the timer command. This covers the basic SBE behaviour expected by skiboot when booting.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20220811093726.1442343-1-npiggin@gmail.com> [danielhb: fixed SBE_HOST_RESPONSE_MASK long line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
#
792e8bb6 |
| 21-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: assign pnv-phb-root-port chassis/slot earlier
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we th
ppc/pnv: assign pnv-phb-root-port chassis/slot earlier
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we think we got.
In fact this is not needed. There is nothing sophisticated being done with the PHB object retrieved during root_port_realize() for both PHB3 and PHB4. We're retrieving a PHB reference just to access phb->chip_id and phb->phb_id and use them to define the chassis/slot of the root port.
phb->phb_id is already being passed to pnv_phb_attach_root_port() via the 'index' parameter. Let's also add a 'chip_id' parameter to this function and assign chassis and slot right there. This will spare us from the hassle of accessing the PHB object inside realize().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220621173436.165912-4-danielhb413@gmail.com>
show more ...
|
#
8625164a |
| 21-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: attach phb3/phb4 root ports in QOM tree
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:
/unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus
ppc/pnv: attach phb3/phb4 root ports in QOM tree
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:
/unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE)
Let's make changes in pnv_phb_attach_root_port() to attach the created root ports to its corresponding PHB.
This is the result afterwards:
/pnv-phb3[0] (pnv-phb3) /lsi (ics) /msi (phb3-msi) /msi32[0] (memory-region) /msi64[0] (memory-region) /pbcq (pnv-pbcq) (...) /phb3_iommu[0] (pnv-phb3-iommu-memory-region) /pnv-phb3-root.0 (pnv-phb3-root) /pnv-phb3-root-port[0] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE)
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-3-danielhb413@gmail.com>
show more ...
|
Revision tags: v7.0.0 |
|
#
9c10d86f |
| 14-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
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 ...
|
#
92499676 |
| 01-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Add a HOMER model to POWER10
Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
|
#
623575e1 |
| 01-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
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 ...
|
#
ae4c68e3 |
| 01-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Add POWER10 quads
and use a pnv_chip_power10_quad_realize() helper to avoid code duplication with P9. This still needs some refinements on the XSCOM registers handling in PnvQuad.
Signed-o
ppc/pnv: Add POWER10 quads
and use a pnv_chip_power10_quad_realize() helper to avoid code duplication with P9. This still needs some refinements on the XSCOM registers handling in PnvQuad.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
8bf682a3 |
| 01-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Add a OCC model for POWER10
Our OCC model is very mininal and POWER10 can simply reuse the OCC model we introduced for POWER9.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signe
ppc/pnv: Add a OCC model for POWER10
Our OCC model is very mininal and POWER10 can simply reuse the OCC model we introduced for POWER9.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
da71b7e3 |
| 01-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Add a XIVE2 controller to the POWER10 chip
The XIVE2 interrupt controller of the POWER10 processor follows the same logic than on POWER9 but the HW interface has been largely reviewed. It
ppc/pnv: Add a XIVE2 controller to the POWER10 chip
The XIVE2 interrupt controller of the POWER10 processor follows the same logic than on POWER9 but the HW interface has been largely reviewed. It has a new register interface, different BARs, extra VSDs, new layout for the XIVE2 structures, and a set of new features which are described below.
This is a model of the POWER10 XIVE2 interrupt controller for the PowerNV machine. It focuses primarily on the needs of the skiboot firmware but some initial hypervisor support is implemented for KVM use (escalation).
Support for new features will be implemented in time and will require new support from the OS.
* XIVE2 BARS
The interrupt controller BARs have a different layout outlined below. Each sub-engine has now own its range and the indirect TIMA access was replaced with a set of pages, one per CPU, under the IC BAR:
- IC BAR (Interrupt Controller) . 4 pages, one per sub-engine . 128 indirect TIMA pages - TM BAR (Thread Interrupt Management Area) . 4 pages - ESB BAR (ESB pages for IPIs) . up to 1TB - END BAR (ESB pages for ENDs) . up to 2TB - NVC BAR (Notification Virtual Crowd) . up to 128 - NVPG BAR (Notification Virtual Process and Group) . up to 1TB - Direct mapped Thread Context Area (reads & writes)
OPAL does not use the grouping and crowd capability.
* Virtual Structure Tables
XIVE2 adds new tables types and also changes the field layout of the END and NVP Virtualization Structure Descriptors.
- EAS - END new layout - NVT was splitted in : . NVP (Processor), 32B . NVG (Group), 32B . NVC (Crowd == P9 block group) 32B - IC for remote configuration - SYNC for cache injection - ERQ for event input queue
The setup is slighly different on XIVE2 because the indexing has changed for some of the tables, block ID or the chip topology ID can be used.
* XIVE2 features
SCOM and MMIO registers have a new layout and XIVE2 adds a new global capability and configuration registers.
The lowlevel hardware offers a set of new features among which :
- a configurable number of priorities : 1 - 8 - StoreEOI with load-after-store ordering is activated by default - Gen2 TIMA layout - A P9-compat mode, or Gen1, TIMA toggle bit for SW compatibility - increase to 24bit for VP number
Other features will have some impact on the Hypervisor and guest OS when activated, but this is not required for initial support of the controller.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
eb93c828 |
| 12-Jan-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Move num_phbs under Pnv8Chip
It is not used elsewhere so that's where it belongs.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-10-danielhb413@gmail.com>
ppc/pnv: Move num_phbs under Pnv8Chip
It is not used elsewhere so that's where it belongs.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
c29dd003 |
| 12-Jan-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. Thi
ppc/pnv: Reparent user created PHB3 devices to the PnvChip
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. This is not the case for user created devices which are parented to the container "/unattached".
Make sure a PHB3 device is parented to its chip by reparenting the object if necessary.
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: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
1f6a88ff |
| 12-Jan-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Introduce support for user created PHB3 devices
PHB3 devices and PCI devices can now be added to the powernv8 machine using :
-device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,
ppc/pnv: Introduce support for user created PHB3 devices
PHB3 devices and PCI devices can now be added to the powernv8 machine using :
-device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,bus=pci.1,addr=0x0
The 'index' property identifies the PHB3 in the chip. In case of user created devices, a lookup on 'chip-id' is required to assign the owning chip.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
a71cd51e |
| 12-Jan-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Attach PHB3 root port device when defaults are enabled
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user create
ppc/pnv: Attach PHB3 root port device when defaults are enabled
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user created PHB3s.
pnv_phb_attach_root_port() is made public in pnv.c so it can be reused with the pnv_phb4 root port later.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
#
422fd92e |
| 17-Dec-2021 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Introduce a num_pecs class attribute for PHB4 PEC devices
POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs :
* PEC0 provides 1 PHB (PHB
ppc/pnv: Introduce a num_pecs class attribute for PHB4 PEC devices
POWER9 processor comes with 3 PHB4 PEC (PCI Express Controller) and each PEC can have several PHBs :
* PEC0 provides 1 PHB (PHB0) * PEC1 provides 2 PHBs (PHB1 and PHB2) * PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5)
A num_pecs class attribute represents better the logic units of the POWER9 chip. Use that instead of num_phbs which fits POWER8 chips. This will ease adding support for user created devices.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211213132830.108372-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
show more ...
|
Revision tags: v6.2.0, v6.1.0 |
|
#
ab17a3fe |
| 09-Aug-2021 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Use a simple incrementing index for the chip-id
When the QEMU PowerNV machine was introduced, multi chip support modeled a two socket system with dual chip modules as found on some P8 Tulet
ppc/pnv: Use a simple incrementing index for the chip-id
When the QEMU PowerNV machine was introduced, multi chip support modeled a two socket system with dual chip modules as found on some P8 Tuleta systems (8286-42A). But this is hardly used and not relevant for QEMU. Use a simple index instead.
With this change, we can now increase the max socket number to 16 as found on high end systems.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210809134547.689560-5-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
show more ...
|
#
6bc8c046 |
| 09-Aug-2021 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Change the POWER10 machine to support DD2 only
There is no need to keep the DD1 chip model as it will never be publicly available.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id
ppc/pnv: Change the POWER10 machine to support DD2 only
There is no need to keep the DD1 chip model as it will never be publicly available.
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210809134547.689560-3-clg@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
show more ...
|