Re: [PATCH v2 1/8] x86/CPU/AMD: Save NodeId on AMD-based systems

From: Borislav Petkov
Date: Thu Sep 10 2020 - 06:15:41 EST

On Wed, Sep 09, 2020 at 03:17:55PM -0500, Yazen Ghannam wrote:
> We need to access specific instances of hardware registers in the
> Northbridge or Data Fabric. The code in arch/x86/kernel/amd_nb.c does
> this.

So you don't need the node_id - you need the northbridge/data fabric ID?
I'm guessing NB == DF, i.e., it was NB before Zen and it is DF now.


> Package = Socket, i.e. a field replaceable unit. Socket may not be
> useful for software, but I think it helps users identify the hardware.
> I think the following could be changed in the documentation:
> "In the past a socket always contained a single package (see below), but
> with the advent of Multi Chip Modules (MCM) a socket can hold more than one
> package."
> Replace "package" with "die".

So first of all, we have:

"AMD nomenclature for package is 'Node'."

so we either change that because as you explain, node != package on AMD.

What you need is the ID of that northbridge or data fabric instance,

> You take multiple dies from the foundry and you "package" them together
> into a single unit.

I think you're overloading the word "package" here and that leads to
more confusion. Package in our definition - Linux' - is:

"Packages contain a number of cores plus shared resources, e.g. DRAM
controller, shared caches etc." If you glue several packages together,
you get an MCM.

> They could be equal depending on the system. The values are different on
> MCM systems like Bulldozer and Naples though.
> The functions and structures in amd_nb.c are indexed by the node_id.
> This is done implicitly right now by using amd_get_nb_id()/cpu_llc_id.
> But the LLC isn't always equal to the Node/Die like in Naples. So the
> patches in this set save and explicitly use the node_id when needed.
> What do you think?

Sounds to me that you want to ID that data fabric instance which
logically belongs to one or multiple packages. Or can a DF a single

So let's start simple: how does a DF instance map to a logical NUMA
node or package? Can a DF serve multiple packages?

You could use the examples at the end of Documentation/x86/topology.rst
to explain how those things play together. And remember to not think
about the physical aspect of the hardware structure because it doesn't
mean anything to software. All you wanna do is address the proper DF
instance so this needs to be enumerable and properly represented by sw.


I am.