| Message ID | 20240526122612.473476-1-npiggin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ppc/pnv: Better big-core model, lpar-per-core, PC unit | expand |
On 5/26/24 14:26, Nicholas Piggin wrote: > Primary motivation for this series is to improve big-core support. > Other things like SPR indirect, timebase state, PC xscom, are required > for minimal big core support. > > I'm still not 100% happy with the big-core topology model after this. > Maybe one day we add pnv big core and pnv small core structures. But I haven't look at the proposal yet, but indeed, we could introduce a new TYPE_PNV_CORE type for big cores only. > nothing is completely clean because big core mode still has certain > small core restrictions. I think for now we take a bit of mostly > abstracted ugliness in TCG code for the benefit of not spreading > hacks through pervasive (xscom) core addressing. > > After this series, power9 and power10 get through skiboot/Linux boot s Have you tried SMT8 on powernv8 ? I remember seeing a hang if I am correct. I don't think POWER8 deserves much attention anymore, we could deprecate POWER8E and POWER8NVL. However, we should at least report an error if we know a setup is broken. Thanks, C. > Not all big core registers are modeled > exactly (some are not shared between small core halves), but that > mostly doesn't matter for OPAL and it can be improved later. > > Thanks, > Nick > > Nicholas Piggin (10): > ppc/pnv: Add pointer from PnvCPUState to PnvCore > ppc/pnv: Move timebase state into PnvCore > target/ppc: Improve SPR indirect registers > ppc/pnv: specialise init for powernv8/9/10 machines > ppc/pnv: Extend chip_pir class method to TIR as well > ppc: Add a core_index to CPUPPCState for SMT vCPUs > target/ppc: Add helpers to check for SMT sibling threads > ppc/pnv: Invert the design for big-core machine modelling > ppc/pnv: Implement POWER10 PC xscom registers for direct controls > ppc/pnv: Add an LPAR per core machine option > > include/hw/core/cpu.h | 8 + > include/hw/ppc/pnv.h | 6 + > include/hw/ppc/pnv_chip.h | 3 +- > include/hw/ppc/pnv_core.h | 31 ++++ > target/ppc/cpu.h | 37 ++--- > hw/ppc/pnv.c | 297 ++++++++++++++++++++++++++++------- > hw/ppc/pnv_chiptod.c | 6 +- > hw/ppc/pnv_core.c | 129 +++++++++++++-- > hw/ppc/spapr_cpu_core.c | 7 + > system/cpus.c | 10 ++ > target/ppc/cpu_init.c | 26 +-- > target/ppc/excp_helper.c | 16 +- > target/ppc/misc_helper.c | 98 ++++++------ > target/ppc/timebase_helper.c | 82 +++++----- > 14 files changed, 548 insertions(+), 208 deletions(-) >
On Mon May 27, 2024 at 4:25 PM AEST, Cédric Le Goater wrote: > On 5/26/24 14:26, Nicholas Piggin wrote: > > Primary motivation for this series is to improve big-core support. > > Other things like SPR indirect, timebase state, PC xscom, are required > > for minimal big core support. > > > > I'm still not 100% happy with the big-core topology model after this. > > Maybe one day we add pnv big core and pnv small core structures. But > > I haven't look at the proposal yet, but indeed, we could introduce > a new TYPE_PNV_CORE type for big cores only. Yeah. It's still tricky because big-core structure contains the CPUs if you are running in small core mode. So it would really have to be a PnvCPUCore and PnvPervasiveCore or something, where the former is either SMT4 and 1:1 with the latter or SMT8 and 1:2 depending on mode. And some of the "CPU" type operations in big core mode still need to operate on the small core. For now, the accessors and helpers seem to be not too bad. > > nothing is completely clean because big core mode still has certain > > small core restrictions. I think for now we take a bit of mostly > > abstracted ugliness in TCG code for the benefit of not spreading > > hacks through pervasive (xscom) core addressing. > > > > After this series, power9 and power10 get through skiboot/Linux boot > s > > Have you tried SMT8 on powernv8 ? I remember seeing a hang if I am correct. > I don't think POWER8 deserves much attention anymore, we could deprecate > POWER8E and POWER8NVL. However, we should at least report an error if we > know a setup is broken. Yeah it does have some problem. Maybe should just disable SMT unless someone finds time to work it out. Thanks, Nick
On 5/27/24 09:32, Nicholas Piggin wrote: > On Mon May 27, 2024 at 4:25 PM AEST, Cédric Le Goater wrote: >> On 5/26/24 14:26, Nicholas Piggin wrote: >>> Primary motivation for this series is to improve big-core support. >>> Other things like SPR indirect, timebase state, PC xscom, are required >>> for minimal big core support. >>> >>> I'm still not 100% happy with the big-core topology model after this. >>> Maybe one day we add pnv big core and pnv small core structures. But >> >> I haven't look at the proposal yet, but indeed, we could introduce >> a new TYPE_PNV_CORE type for big cores only. > > Yeah. It's still tricky because big-core structure contains the CPUs > if you are running in small core mode. So it would really have to be > a PnvCPUCore and PnvPervasiveCore or something, where the former is > either SMT4 and 1:1 with the latter or SMT8 and 1:2 depending on mode. > > And some of the "CPU" type operations in big core mode still need to > operate on the small core. > > For now, the accessors and helpers seem to be not too bad. > >>> nothing is completely clean because big core mode still has certain >>> small core restrictions. I think for now we take a bit of mostly >>> abstracted ugliness in TCG code for the benefit of not spreading >>> hacks through pervasive (xscom) core addressing. >>> >>> After this series, power9 and power10 get through skiboot/Linux boot >> s >> >> Have you tried SMT8 on powernv8 ? I remember seeing a hang if I am correct. >> I don't think POWER8 deserves much attention anymore, we could deprecate >> POWER8E and POWER8NVL. However, we should at least report an error if we >> know a setup is broken. > > Yeah it does have some problem. Maybe should just disable SMT unless > someone finds time to work it out. The new _init routines would be a good place to do that. Thanks, C. > > Thanks, > Nick