Re: [PATCH V6 0/7] ACPI: Support Generic Initiator proximity domains

[Jonathan Cameron]

On Wed, 18 Dec 2019 12:32:06 +0100
Brice Goglin <brice.goglin@xxxxxxxxx> wrote:

> Le 16/12/2019 à 16:38, Jonathan Cameron a écrit :
> > Introduces a new type of NUMA node for cases where we want to represent
> > the access characteristics of a non CPU initiator of memory requests,
> > as these differ from all those for existing nodes containing CPUs and/or
> > memory.
> >
> > These Generic Initiators are presented by the node access0 class in
> > sysfs in the same way as a CPU.   It seems likely that there will be
> > usecases in which the best 'CPU' is desired and Generic Initiators
> > should be ignored.  The final few patches in this series introduced
> > access1 which is a new performance class in the sysfs node description
> > which presents only CPU to memory relationships.  Test cases for this
> > are described below.  
> 
> 
> Hello Jonathan
> 
> If I want to test this with a fake GI, what are the minimal set of
> changes I should put in my ACPI tables? Can I just specify a dummy GI in
> SRAT? What handle should I use there?

Exactly that for a dummy GI.  Also extend HMAT and SLIT for the extra
proximity domain / initiator.

For the handle, anything is fine.  This patch set doesn't currently use it.
That handle was a bit controversial when this spec feature was being
discussed because it can 'disagree' with information from _PXM.

The ACPI spec ended up effectively relying on them agreeing.  So any handle
must identify a device that either doesn't have a _PXM entry or that
has one that refers to the same proximity domain.

Also note there is a fiddly corner case which is covered by an _OSC.
If you have a device that you want to use _PXM to put in a GI only
domain then older kernels will not know about the GI domain. Hence
ACPI goes through a dance to ensure that a kernel that hasn't
announced it is GI aware, doesn't get told anything is in a GI only domain.
For testing this series though you can just ignore that.

The logic to actually pass that handle based specification through to the
devices is complex, so this set relies on _PXM in DSDT to actually associate
any device with the Generic Initiator domain.  If doing this for a PCI
device, note that you need the fix mentioned in the cover letter to actually
have _PXM apply to PCI EPs.  Note that the _PXM case needs to work anyway
as you might have a GI node with multiple GIs and there is no obligation
for them all to be specified in SRAT.

Once this initial set is in place we can work out how to use the SRAT
handle to associate it with a device.  To be honest, I haven't really
thought about how we'd do that yet.

Thanks,

Jonathan


> 
> Thanks
> 
> Brice
> 
>