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
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
in SMT8 big-core mode. 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(-)

-- 
2.43.0

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