summary refs log tree commit diff stats
path: root/hw/ppc/pnv.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'pull-ppc-for-9.0-2-20240313' of https://gitlab.com/npiggin/qemu ↵Peter Maydell2024-03-131-32/+143
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging * PAPR nested hypervisor host implementation for spapr TCG * excp_helper.c code cleanups and improvements * Move more ops to decodetree * Deprecate pseries-2.12 machines and P9 and P10 DD1.0 CPUs * Document running Linux on AmigaNG * Update dt feature advertising POWER CPUs. * Add P10 PMU SPRs * Improve pnv topology calculation for SMT8 CPUs. * Various bug fixes. # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEETkN92lZhb0MpsKeVZ7MCdqhiHK4FAmXwiT8ACgkQZ7MCdqhi # HK7C/w//XxEO2bQTFPLFDTrP/voq7pcX8XeQNVyXCkXYjvsbu05oQow50k+Y5UAE # US4MFjt8jFz0vuIKuKyoA3kG41zDSOzoX4TQXMM+tyTWbuFF3KAyfizb1xE6SYAN # xJEGvmiXv/EgoSBD7BTKQp1tMPdIGZLwSdYiA0lmOo7YaMCgYAXaujW5hnNjQecT # 873sN+10pHtQY++mINtD9Nfb6AcDGMWw0b+bykqIXhNRkI8IGOS4WF4vAuMBrwfe # UM00wDnNRb86Dk14bv2XVNDr6/i0VRtUMwM4yiptrQ1TQx18LZaPSQFYjQfPaan7 # LwN4QkMFnBX54yJ7Npvjvu8BCBF47kwOVu4CIAFJ4sIm0WfTmozDpPttwcZ5w7Ve # iXDOB9ECAB4pQ2rCgbSNG8MYUZgoHHOuThqolOP0Vh9NHRRJxpdw6CyAbmCGftc0 # lvRDPFiKp8xmCNJ/j3XzoUdHoG7NMwpUmHv9ruGU18SdQ8hyJN9AcQGWYrB4v0RV # /hs2RAbwntG7ahkcwd8uy5aFw88Wph/uGXPXc49EWj7i49vHeIV2y5+gtthMywje # qqjFXkistXuF+JHVnyoYmqqCyXaHX5CEwtawMv4EQeaJs76bLhMeMTKKl9rRp8qB # DtbIZphO8iMsocrBnje48sA5HR0PM+H4HTjw10i8R0fLlWitaIY= # =XnY5 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 16:56:31 GMT # gpg: using RSA key 4E437DDA56616F4329B0A79567B30276A8621CAE # gpg: Good signature from "Nicholas Piggin <npiggin@gmail.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 4E43 7DDA 5661 6F43 29B0 A795 67B3 0276 A862 1CAE * tag 'pull-ppc-for-9.0-2-20240313' of https://gitlab.com/npiggin/qemu: (38 commits) spapr: nested: Introduce cap-nested-papr for Nested PAPR API spapr: nested: Introduce H_GUEST_RUN_VCPU hcall. spapr: nested: Use correct source for parttbl info for nested PAPR API. spapr: nested: Introduce H_GUEST_[GET|SET]_STATE hcalls. spapr: nested: Initialize the GSB elements lookup table. spapr: nested: Extend nested_ppc_state for nested PAPR API spapr: nested: Introduce H_GUEST_CREATE_VCPU hcall. spapr: nested: Introduce H_GUEST_[CREATE|DELETE] hcalls. spapr: nested: Introduce H_GUEST_[GET|SET]_CAPABILITIES hcalls. spapr: nested: Document Nested PAPR API spapr: nested: keep nested-hv related code restricted to its API. spapr: nested: Introduce SpaprMachineStateNested to store related info. spapr: nested: move nested part of spapr_get_pate into spapr_nested.c spapr: nested: register nested-hv api hcalls only for cap-nested-hv target/ppc: Remove interrupt handler wrapper functions target/ppc: Clean up ifdefs in excp_helper.c, part 3 target/ppc: Clean up ifdefs in excp_helper.c, part 2 target/ppc: Clean up ifdefs in excp_helper.c, part 1 target/ppc: Add gen_exception_err_nip() function target/ppc: Readability improvements in exception handlers ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * ppc/pnv: Improve pervasive topology calculation for big-coreCaleb Schlossin2024-03-131-20/+51
| | | | | | | | | | | | | | | | | | Big (SMT8) cores have a complicated function to map the core, thread ID to pervasive topology (PIR). Fix this for power8, power9, and power10. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Caleb Schlossin <calebs@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
| * ppc/pnv: Set POWER9, POWER10 ibm,pa-features bitsNicholas Piggin2024-03-131-2/+65
| | | | | | | | | | | | | | | | Copy the pa-features arrays from spapr, adjusting slightly as described in comments. Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
| * ppc/pnv: Permit ibm,pa-features set per machine variantNicholas Piggin2024-03-131-12/+29
| | | | | | | | | | | | | | This allows different pa-features for powernv8/9/10. Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
| * ppc/spapr|pnv: Remove SAO from pa-featuresNicholas Piggin2024-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | SAO is a page table attribute that strengthens the memory ordering of accesses. QEMU with MTTCG does not implement this, so clear it in ibm,pa-features. This is an obscure feature that has been removed from POWER10 ISA v3.1, there isn't much concern with removing it. Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* | target/ppc: Prefer fast cpu_env() over slower CPU QOM cast macroPhilippe Mathieu-Daudé2024-03-121-2/+1
| | | | | | | | | | | | | | | | | | | | Mechanical patch produced running the command documented in scripts/coccinelle/cpu_env.cocci_template header. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240129164514.73104-22-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
* | bulk: Access existing variables initialized to &S->F when availablePhilippe Mathieu-Daudé2024-03-121-10/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a variable is initialized to &struct->field, use it in place. Rationale: while this makes the code more concise, this also helps static analyzers. Mechanical change using the following Coccinelle spatch script: @@ type S, F; identifier s, m, v; @@ S *s; ... F *v = &s->m; <+... - &s->m + v ...+> Inspired-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240129164514.73104-2-philmd@linaro.org> Acked-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [thuth: Dropped hunks that need a rebase, and fixed sizeof() in pmu_realize()] Signed-off-by: Thomas Huth <thuth@redhat.com>
* ppc/pnv: Implement the ChipTOD to Core transferNicholas Piggin2024-02-231-0/+15
| | | | | | | | | | | | | | | | | | One of the functions of the ChipTOD is to transfer TOD to the Core (aka PC - Pervasive Core) timebase facility. The ChipTOD can be programmed with a target address to send the TOD value to. The hardware implementation seems to perform this by sending the TOD value to a SCOM address. This implementation grabs the core directly and manipulates the timebase facility state in the core. This is a hack, but it works enough for now. A better implementation would implement the transfer to the PnvCore xscom register and drive the timebase state machine from there. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: Wire ChipTOD model to powernv9 and powernv10 machinesNicholas Piggin2024-02-231-0/+30
| | | | | | | | Wire the ChipTOD model to powernv9 and powernv10 machines. Suggested-by-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* hw/ppc: N1 chiplet wiringChalapathi V2024-02-231-0/+15
| | | | | | | | This part of the patchset connects the nest1 chiplet model to p10 chip. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Chalapathi V <chalapathi.v@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: Add a pca9554 I2C device to powernv10-rainierGlenn Miles2024-02-231-0/+6
| | | | | | | | | | | For powernv10-rainier, the Power Hypervisor code expects to see a pca9554 device connected to the 3rd PNV I2C engine on port 1 at I2C address 0x25 (or left-justified address of 0x4A). This is used by the hypervisor code to detect if a "Cable Card" is present. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: Wire up pca9552 GPIO pins for PCIe hotplug power controlGlenn Miles2024-02-231-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For power10-rainier, a pca9552 device is used for PCIe slot hotplug power control by the Power Hypervisor code. The code expects that some time after it enables power to a PCIe slot by asserting one of the pca9552 GPIO pins 0-4, it should see a "power good" signal asserted on one of pca9552 GPIO pins 5-9. To simulate this behavior, we simply connect the GPIO outputs for pins 0-4 to the GPIO inputs for pins 5-9. Each PCIe slot is assigned 3 GPIO pins on the pca9552 device, for control of up to 5 PCIe slots. The per-slot signal names are: SLOTx_EN.......PHYP uses this as an output to enable slot power. We connect this to the SLOTx_PG pin to simulate a PGOOD signal. SLOTx_PG.......PHYP uses this as in input to detect PGOOD for the slot. For our purposes we just connect this to the SLOTx_EN output. SLOTx_Control..PHYP uses this as an output to prevent a race condition in the real hotplug circuitry, but we can ignore this output for simulation. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: Add pca9552 to powernv10-rainier for PCIe hotplug power controlGlenn Miles2024-02-231-0/+25
| | | | | | | | | | | The Power Hypervisor code expects to see a pca9552 device connected to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or left- justified address of 0xC6). This is used by hypervisor code to control PCIe slot power during hotplug events. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: New powernv10-rainier machine typeGlenn Miles2024-02-231-2/+22
| | | | | | | | | Create a new powernv machine type, powernv10-rainier, that will contain rainier-specific devices. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: Change powernv default to powernv10Nicholas Piggin2024-02-231-2/+2
| | | | | | | | | | POWER10 is the latest IBM Power machine. Although it is not offered in "OPAL mode" (i.e., powernv configuration), so there is a case that it should remain at powernv9, most of the development work is going into powernv10 at the moment. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
* ppc/pnv: PNV I2C engines assigned incorrect XSCOM addressesGlenn Miles2023-11-211-2/+4
| | | | | | | | | | | | | | The PNV I2C engines for power9 and power10 were being assigned a base XSCOM address that was off by one I2C engine's address range such that engine 0 had engine 1's address and so on. The xscom address assignment was being based on the device tree engine numbering, which starts at 1. Rather than changing the device tree numbering to start with 0, the addressing was changed to be based on the existing device tree numbers minus one. Fixes: 1ceda19c28a1 ("ppc/pnv: Connect PNV I2C controller to powernv10) Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* ppc/pnv: Fix number of I2C engines and ports for power9/10Glenn Miles2023-11-071-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Power9 is supposed to have 4 PIB-connected I2C engines with the following number of ports on each engine: 0: 2 1: 13 2: 2 3: 2 Power10 also has 4 engines but has the following number of ports on each engine: 0: 14 1: 14 2: 2 3: 16 Current code assumes that they all have the same (maximum) number. This can be a problem if software expects to see a certain number of ports present (Power Hypervisor seems to care). Fixed this by adding separate tables for power9 and power10 that map the I2C controller number to the number of I2C buses that should be attached for that engine. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Message-ID: <20231025152714.956664-1-milesg@linux.vnet.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: Connect PNV I2C controller to powernv10Glenn Miles2023-11-071-0/+29
| | | | | | | | | | | | | | Wires up four I2C controller instances to the powernv10 chip XSCOM address space. Each controller instance is wired up to two I2C buses of its own. No other I2C devices are connected to the buses at this time. Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-ID: <20231017221434.810363-1-milesg@linux.vnet.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: Connect I2C controller model to powernv9 chipCédric Le Goater2023-11-071-0/+28
| | | | | | | | | | | | | | | | | | | Wires up three I2C controller instances to the powernv9 chip XSCOM address space. Each controller instance is wired up to a single I2C bus of its own. No other I2C devices are connected to the buses at this time. Signed-off-by: Cédric Le Goater <clg@kaod.org> [milesg: Split wiring from addition of model itself] [milesg: Added new commit message] [milesg: Moved hardcoded attributes into PnvChipClass] [milesg: Removed TODO comment for I2C] Signed-off-by: Glenn Miles <milesg@linux.vnet.ibm.com> Acked-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-ID: <20231016222013.3739530-3-milesg@linux.vnet.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* hw/ppc/pnv: Do not use SysBus API to map local MMIO regionPhilippe Mathieu-Daudé2023-10-191-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is no point in exposing an internal MMIO region via SysBus and directly mapping it in the very same device. Just map it without using the SysBus API. Transformation done using the following coccinelle script: @@ expression sbdev; expression index; expression addr; expression subregion; @@ - sysbus_init_mmio(sbdev, subregion); ... when != sbdev - sysbus_mmio_map(sbdev, index, addr); + memory_region_add_subregion(get_system_memory(), addr, subregion); Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20231019131647.19690-6-philmd@linaro.org>
* hw/ppc/pnv_xscom: Move sysbus_mmio_map() call within pnv_xscom_init()Philippe Mathieu-Daudé2023-10-191-6/+3
| | | | | | | | | | | | In order to make the next commit trivial, move sysbus_init_mmio() calls just before the corresponding sysbus_mmio_map() calls. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20231019131647.19690-4-philmd@linaro.org>
* hw/ppc/pnv_xscom: Rename pnv_xscom_realize(Error **) -> pnv_xscom_init()Philippe Mathieu-Daudé2023-10-191-15/+3
| | | | | | | | | | | | pnv_xscom_realize() is not used to *realize* QDev object, rename it as pnv_xscom_init(). The Error** argument is unused: remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20231019131647.19690-3-philmd@linaro.org>
* ppc/pnv: Add QME region for P10Joel Stanley2023-07-071-0/+3
| | | | | | | | | | | | | | | | | | | The Quad Management Engine (QME) manages power related settings for its quad. The xscom region is separate from the quad xscoms, therefore a new region is added. The xscoms in a QME select a given core by selecting the forth nibble. Implement dummy reads for the stop state history (SSH) and special wakeup (SPWU) registers. This quietens some sxcom errors when skiboot boots on p10. Power9 does not have a QME. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Message-ID: <20230707071213.9924-1-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: SMT support for powernvNicholas Piggin2023-07-071-0/+12
| | | | | | | | | | | | | | | | Set the TIR default value with the SMT thread index, and place some standard limits on SMT configurations. Now powernv is able to boot skiboot and Linux with a SMT topology, including booting a KVM guest. There are several SPRs and other features (e.g., broadcast msgsnd) that are not implemented, but not used by OPAL or Linux and can be added incrementally. Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-ID: <20230705120631.27670-4-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: Add P10 quad xscom modelJoel Stanley2023-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | Add a PnvQuad class for the P10 powernv machine. No xscoms are implemented yet, but this allows them to be added. The size is reduced to avoid the quad region from overlapping with the core region. address-space: xscom-0 0000000000000000-00000003ffffffff (prio 0, i/o): xscom-0 0000000100000000-00000001000fffff (prio 0, i/o): xscom-quad.0 0000000100108000-0000000100907fff (prio 0, i/o): xscom-core.3 0000000100110000-000000010090ffff (prio 0, i/o): xscom-core.2 0000000100120000-000000010091ffff (prio 0, i/o): xscom-core.1 0000000100140000-000000010093ffff (prio 0, i/o): xscom-core.0 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230704054204.168547-4-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: Subclass quad xscom callbacksJoel Stanley2023-07-071-4/+7
| | | | | | | | | | | Make the existing pnv_quad_xscom_read/write be P9 specific, in preparation for a different P10 callback. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230704054204.168547-3-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* ppc/pnv: Rephrase error when run with KVMCédric Le Goater2023-06-251-1/+2
| | | | | | | Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* target/ppc: Add POWER9 DD2.2 modelNicholas Piggin2023-05-281-1/+1
| | | | | | | | | | | | | | | | | 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>
* pnv_phb4_pec: Simplify/align code to parent user-created PHBsFrederic Barrat2023-03-031-21/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pnv_phb4_pec: Move pnv_phb4_get_pec() to rightful fileFrederic Barrat2023-03-031-43/+1
| | | | | | | | | | | | | | | | | | | 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>
* pnv_phb4_pec: Keep track of instantiated PHBsFrederic Barrat2023-03-031-0/+1
| | | | | | | | | | | | 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>
* include/hw/ppc: Split pnv_chip.h off pnv.hMarkus Armbruster2023-01-201-0/+3
| | | | | | | | | | | | | | | | | | | | 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>
* reset: allow registering handlers that aren't called by snapshot loadingJason A. Donenfeld2022-10-271-2/+2
| | | | | | | | | | | | | Snapshot loading only expects to call deterministic handlers, not non-deterministic ones. So introduce a way of registering handlers that won't be called when reseting for snapshots. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-id: 20221025004327.568476-2-Jason@zx2c4.com [PMM: updated json doc comment with Markus' text; fixed checkpatch style nit] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/ppc: set machine->fdt in pnv_reset()Daniel Henrique Barboza2022-10-171-1/+7
| | | | | | | | | | This will enable support for the 'dumpdtb' QMP/HMP command for all powernv machines. Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220926173855.1159396-13-danielhb413@gmail.com>
* hw/ppc/pnv: Avoid dynamic stack allocationPhilippe Mathieu-Daudé2022-09-221-2/+2
| | | | | | | | | | | | Use autofree heap allocation instead of variable-length array on the stack. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-id: 20220819153931.3147384-7-peter.maydell@linaro.org
* ppc/pnv: user creatable pnv-phb for powernv10Daniel Henrique Barboza2022-08-311-0/+2
| | | | | | | | | | | Given that powernv9 and powernv10 uses the same pnv-phb backend, the logic to allow user created pnv-phbs for powernv10 is already in place. Let's flip the switch. 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-11-danielhb413@gmail.com>
* ppc/pnv: change pnv_phb4_get_pec() to also retrieve chip10->pecsDaniel Henrique Barboza2022-08-311-2/+15
| | | | | | | | | | | | | | The function assumes that we're always dealing with a PNV9_CHIP() object. This is not the case when the pnv-phb device belongs to a powernv10 machine. Change pnv_phb4_get_pec() to be able to work with PNV10_CHIP() if necessary. 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-10-danielhb413@gmail.com>
* ppc/pnv: enable user created pnv-phb for powernv9Daniel Henrique Barboza2022-08-311-0/+2
| | | | | | | | | | 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>
* ppc/pnv: add PHB4 helpers for user created pnv-phbDaniel Henrique Barboza2022-08-311-3/+32
| | | | | | | | | | | | | | | | | | The PHB4 backend relies on a link with the corresponding PEC element. This is trivial to do during machine_init() time for default devices, but not so much for user created ones. pnv_phb4_get_pec() is a small variation of the function that was reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". We'll use it to determine the appropriate PEC for a given user created pnv-phb that uses a PHB4 backend. This is done during realize() time, in pnv_phb_user_device_init(). 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-8-danielhb413@gmail.com>
* ppc/pnv: enable user created pnv-phb for powernv8Daniel Henrique Barboza2022-08-311-14/+18
| | | | | | | | | | | | The bulk of the work was already done by previous patches. Use defaults_enabled() to determine whether we need to create the default devices or not. 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-7-danielhb413@gmail.com>
* ppc/pnv: turn chip8->phbs[] into a PnvPHB* arrayDaniel Henrique Barboza2022-08-311-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza2022-08-311-0/+20
| | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza2022-08-311-25/+0
| | | | | | | | 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>
* ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza2022-08-311-4/+5
| | | | | | | | 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>
* ppc/pnv: remove pnv-phb4-root-portDaniel Henrique Barboza2022-08-311-0/+2
| | | | | | | | | | 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>
* ppc/pnv: remove pnv-phb3-root-portDaniel Henrique Barboza2022-08-311-0/+1
| | | | | | | | | | The unified pnv-phb-root-port can be used in its place. There is no ABI breakage in doing so because no official QEMU release introduced user creatable pnv-phb3-root-port devices. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-8-danielhb413@gmail.com>
* ppc/pnv: turn PnvPHB4 into a PnvPHB backendDaniel Henrique Barboza2022-08-311-3/+17
| | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza2022-08-311-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ppc/pnv: Add initial P9/10 SBE modelNicholas Piggin2022-08-311-0/+25
| | | | | | | | | | | | | | | | | | 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>
* target/ppc: Fix host PVR matching for KVMNicholas Piggin2022-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ppc_cpu_compare_class_pvr_mask() should match the best CPU class in the family, because it is used by the KVM subsystem to find the host CPU class. Since commit 03ae4133ab8 ("target-ppc: Add pvr_match() callback"), it matches any class in the family (the first one in the comparison list). Since commit f30c843ced5 ("ppc/pnv: Introduce PowerNV machines with fixed CPU models"), pnv has relied on pnv_match having these new semantics to check machine compatibility with a CPU family. Resolve this by adding a parameter to the pvr_match function to select the best or any match, and restore the old behaviour for the KVM case. Prior to this fix, e.g., a POWER9 DD2.3 KVM host matches to the power9_v1.0 class (because that happens to be the first POWER9 family CPU compared). After the patch, it matches the power9_v2.0 class. This approach requires pnv_match contain knowledge of the CPU classes implemented in the same family, which feels ugly. But pushing the 'best' match down to the class would still require they know about one another which is not obviously much better. For now this gets things working. Fixes: 03ae4133ab8 ("target-ppc: Add pvr_match() callback") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220731013358.170187-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>