qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/4] ppc/pnv: Extend "quad" model for p10


From: Nicholas Piggin
Subject: Re: [PATCH 0/4] ppc/pnv: Extend "quad" model for p10
Date: Sat, 01 Jul 2023 20:10:51 +1000

On Fri Jun 30, 2023 at 1:55 PM AEST, Joel Stanley wrote:
> The quad model implements the EC xscoms for the p9 machine, reusing the
> same model for p10 which isn't quite correct. This series adds a PnvQuad
> class and subclasses it for P9 and P10. Implement the core thread state
> xscom as an example. I expect more function to be implemented in future
> patches.
>
> There's one outstanding question. Skiboot has this for the p10 scom:
>
>  #define P10_EC_CORE_THREAD_STATE        0x412
>
> However the read that comes is for 0x28412. I suspect the upper 0x28000
> are addressing bits, so we're really reporting the core thread state for
> the given core. Should the model instead wired so one is created for
> each chiplet? Or should we report the value for all possible cores, like
> the P9 code does for P9X_EX_NCU_SPEC_BAR?
>
>     switch (offset) {
>     case P9X_EX_NCU_SPEC_BAR:
>     case P9X_EX_NCU_SPEC_BAR + 0x400: /* Second EX */

Yes you're right, 0x28000 is addressing within the quad. The 0x2 selects
core/cache/NCU/etc and the 8 is a one-hot encoding to select the core.

So this access should actually be redirected to the pnv core scoms. I
think to make that work, those regions have to be a subregion of the
quad, right now they seem to overlap (the sizes are a bit wrong too,
they end up overlapping).

0x412 is then a register in a particular core's "PC" unit. I assume PC
is probably 0x800 or 0x1000 in size.

The quad itself has a QME engine, so you might address that with the
quad registers.

IIRC the actual topology is something like

EQ +--- EX +--- ECL2 +--- EC
   |       +--- L3   +--- L2 
   +--- QME          +--- NCU
   +--- maybe some scom and sensor stuff

No point modeling all that of course, just per-core and per-quad regions
like it already has for now. But if for example we wanted to model some
registers in the L2, it would not be contiguous with the core addresses
so we'd have to add it.

Thanks,
Nick

>
> Joel Stanley (4):
>   ppc/pnv: quad xscom callbacks are P9 specific
>   ppc/pnv: Subclass quad xscom callbacks
>   ppc/pnv: Add P10 quad ops
>   ppc/pnv: Return zero for core thread state xscom
>
>  include/hw/ppc/pnv_core.h |  12 +++-
>  hw/ppc/pnv.c              |  11 ++--
>  hw/ppc/pnv_core.c         | 114 +++++++++++++++++++++++++++++++-------
>  3 files changed, 113 insertions(+), 24 deletions(-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]