linux.git/drivers/acpi, branch v6.6.118

ACPI: HMAT: Remove register of memory node for generic target

2025-11-24T09:30:14+00:00

commit 54b9460b0a28c4c76a7b455ec1b3b61a13e97291 upstream.

For generic targets, there's no reason to call
register_memory_node_under_compute_node() with the access levels that are
only visible to HMAT handling code. Only update the attributes and rename
hmat_register_generic_target_initiators() to hmat_update_generic_target().

The original call path ends up triggering register_memory_node_under_compute_node().
Although the access level would be "3" and not impact any current node arrays, it
introduces unwanted data into the numa node access_coordinate array.

Fixes: a3a3e341f169 ("acpi: numa: Add setting of generic port system locality attributes")
Cc: Rafael J. Wysocki 
Reviewed-by: Jonathan Cameron 
Tested-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Link: https://lore.kernel.org/r/20240308220055.2172956-2-dave.jiang@intel.com
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

acpi/hmat: Fix lockdep warning for hmem_register_resource()

2025-11-24T09:30:04+00:00

[ Upstream commit 214291cbaaceeb28debd773336642b1fca393ae0 ]

The following lockdep splat was observed while kernel auto-online a CXL
memory region:

======================================================
WARNING: possible circular locking dependency detected
6.17.0djtest+ #53 Tainted: G        W
------------------------------------------------------
systemd-udevd/3334 is trying to acquire lock:
ffffffff90346188 (hmem_resource_lock){+.+.}-{4:4}, at: hmem_register_resource+0x31/0x50

but task is already holding lock:
ffffffff90338890 ((node_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x2e/0x70

which lock already depends on the new lock.
[..]
Chain exists of:
  hmem_resource_lock --> mem_hotplug_lock --> (node_chain).rwsem

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  rlock((node_chain).rwsem);
                               lock(mem_hotplug_lock);
                               lock((node_chain).rwsem);
  lock(hmem_resource_lock);

The lock ordering can cause potential deadlock. There are instances
where hmem_resource_lock is taken after (node_chain).rwsem, and vice
versa.

Split out the target update section of hmat_register_target() so that
hmat_callback() only envokes that section instead of attempt to register
hmem devices that it does not need to.

[ dj: Fix up comment to be closer to 80cols. (Jonathan) ]

Fixes: cf8741ac57ed ("ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device")
Reviewed-by: Jonathan Cameron 
Tested-by: Smita Koralahalli 
Reviewed-by: Smita Koralahalli 
Reviewed-by: Dan Williams 
Link: https://patch.msgid.link/20251105235115.85062-3-dave.jiang@intel.com
Signed-off-by: Dave Jiang 
Signed-off-by: Sasha Levin

base/node / ACPI: Enumerate node access class for 'struct access_coordinate'

2025-11-24T09:30:04+00:00

[ Upstream commit 11270e526276ffad4c4237acb393da82a3287487 ]

Both generic node and HMAT handling code have been using magic numbers to
indicate access classes for 'struct access_coordinate'. Introduce enums to
enumerate the access0 and access1 classes shared by the two subsystems.
Update the function parameters and callers as appropriate to utilize the
new enum.

Access0 is named to ACCESS_COORDINATE_LOCAL in order to indicate that the
access class is for 'struct access_coordinate' between a target node and
the nearest initiator node.

Access1 is named to ACCESS_COORDINATE_CPU in order to indicate that the
access class is for 'struct access_coordinate' between a target node and
the nearest CPU node.

Cc: Greg Kroah-Hartman 
Cc: Rafael J. Wysocki 
Reviewed-by: Jonathan Cameron 
Tested-by: Jonathan Cameron 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Dave Jiang 
Link: https://lore.kernel.org/r/20240308220055.2172956-3-dave.jiang@intel.com
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi: numa: Add setting of generic port system locality attributes

2025-11-24T09:30:04+00:00

[ Upstream commit a3a3e341f169511823f7b2d140a0bdfbd620dcbd ]

Add generic port support for the parsing of HMAT system locality sub-table.
The attributes will be added to the third array member of the access
coordinates in order to not mix with the existing memory attributes. It
only provides the system locality attributes from initiator to the
generic port targets and is missing the rest of the data to the actual
memory device.

The complete attributes will be updated when a memory device is
attached and the system locality information is calculated end to end.

Through hmat_update_target_attrs(), the best performance attributes will
be setup in target->coord.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/170319618135.2212653.13778540010384821833.stgit@djiang5-mobl3
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi: Break out nesting for hmat_parse_locality()

2025-11-24T09:30:04+00:00

[ Upstream commit 79205651120620c2683f90c25ef3d2ac8e454026 ]

Refactor hmat_parse_locality() to break up the deep nesting of the
function.

Suggested-by: Jonathan Cameron 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/170319617537.2212653.10625501075519862509.stgit@djiang5-mobl3
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi: numa: Add genport target allocation to the HMAT parsing

2025-11-24T09:30:03+00:00

[ Upstream commit 6373c48b8c9dfb5c1e09fdb538e700d9cc91c45e ]

Add SRAT parsing for the HMAT init in order to collect the device handle
from the Generic Port Affinity Structure. The device handle will serve as
the key to search for target data.

Consolidate the common code with alloc_memory_target() in a helper function
alloc_target().

Reviewed-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/170319616951.2212653.14862375982250406464.stgit@djiang5-mobl3
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi: numa: Create enum for memory_target access coordinates indexing

2025-11-24T09:30:03+00:00

[ Upstream commit 69b789b64456093819f730b3f9c13a593a5485d9 ]

Create enums to provide named indexing for the access coordinate array.
This is in preparation for adding generic port support which will add a
third index in the array to keep the generic port attributes separate from
the memory attributes.

Reviewed-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Acked-by: Rafael J. Wysocki 
Link: https://lore.kernel.org/r/170319616332.2212653.3872789279950567889.stgit@djiang5-mobl3
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

base/node / acpi: Change 'node_hmem_attrs' to 'access_coordinates'

2025-11-24T09:30:03+00:00

[ Upstream commit 6a954e94d038f41d79c4e04348c95774d1c9337d ]

Dan Williams suggested changing the struct 'node_hmem_attrs' to
'access_coordinates' [1]. The struct is a container of r/w-latency and
r/w-bandwidth numbers. Moving forward, this container will also be used by
CXL to store the performance characteristics of each link hop in
the PCIE/CXL topology. So, where node_hmem_attrs is just the access
parameters of a memory-node, access_coordinates applies more broadly
to hardware topology characteristics. The observation is that seemed like
an exercise in having the application identify "where" it falls on a
spectrum of bandwidth and latency needs. For the tuple of
read/write-latency and read/write-bandwidth, "coordinates" is not a perfect
fit. Sometimes it is just conveying values in isolation and not a
"location" relative to other performance points, but in the end this data
is used to identify the performance operation point of a given memory-node.
[2]

Link: http://lore.kernel.org/r/64471313421f7_1b66294d5@dwillia2-xfh.jf.intel.com.notmuch/
Link: https://lore.kernel.org/linux-cxl/645e6215ee0de_1e6f2945e@dwillia2-xfh.jf.intel.com.notmuch/
Suggested-by: Dan Williams 
Reviewed-by: Dan Williams 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Dave Jiang 
Acked-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/170319615734.2212653.15319394025985499185.stgit@djiang5-mobl3
Signed-off-by: Dan Williams 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi, hmat: calculate abstract distance with HMAT

2025-11-24T09:30:03+00:00

[ Upstream commit 3718c02dbd4c88d47b5af003acdb3d1112604ea3 ]

A memory tiering abstract distance calculation algorithm based on ACPI
HMAT is implemented.  The basic idea is as follows.

The performance attributes of system default DRAM nodes are recorded as
the base line.  Whose abstract distance is MEMTIER_ADISTANCE_DRAM.  Then,
the ratio of the abstract distance of a memory node (target) to
MEMTIER_ADISTANCE_DRAM is scaled based on the ratio of the performance
attributes of the node to that of the default DRAM nodes.

The functions to record the read/write latency/bandwidth of the default
DRAM nodes and calculate abstract distance according to read/write
latency/bandwidth ratio will be used by CXL CDAT (Coherent Device
Attribute Table) and other memory device drivers.  So, they are put in
memory-tiers.c.

Link: https://lkml.kernel.org/r/20230926060628.265989-4-ying.huang@intel.com
Signed-off-by: "Huang, Ying" 
Tested-by: Bharata B Rao 
Reviewed-by: Dave Jiang 
Reviewed-by: Alistair Popple 
Cc: Aneesh Kumar K.V 
Cc: Wei Xu 
Cc: Dan Williams 
Cc: Dave Hansen 
Cc: Davidlohr Bueso 
Cc: Johannes Weiner 
Cc: Jonathan Cameron 
Cc: Michal Hocko 
Cc: Yang Shi 
Cc: Rafael J Wysocki 
Signed-off-by: Andrew Morton 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin

acpi, hmat: refactor hmat_register_target_initiators()

2025-11-24T09:30:03+00:00

[ Upstream commit d0376aac59a166cd7bd9d1a9768e31e71002631b ]

Previously, in hmat_register_target_initiators(), the performance
attributes are calculated and the corresponding sysfs links and files are
created too.  Which is called during memory onlining.

But now, to calculate the abstract distance of a memory target before
memory onlining, we need to calculate the performance attributes for a
memory target without creating sysfs links and files.

To do that, hmat_register_target_initiators() is refactored to make it
possible to calculate performance attributes separately.

Link: https://lkml.kernel.org/r/20230926060628.265989-3-ying.huang@intel.com
Signed-off-by: "Huang, Ying" 
Reviewed-by: Alistair Popple 
Tested-by: Alistair Popple 
Tested-by: Bharata B Rao 
Reviewed-by: Dave Jiang 
Cc: Aneesh Kumar K.V 
Cc: Wei Xu 
Cc: Dan Williams 
Cc: Dave Hansen 
Cc: Davidlohr Bueso 
Cc: Johannes Weiner 
Cc: Jonathan Cameron 
Cc: Michal Hocko 
Cc: Yang Shi 
Cc: Rafael J Wysocki 
Signed-off-by: Andrew Morton 
Stable-dep-of: 214291cbaace ("acpi/hmat: Fix lockdep warning for hmem_register_resource()")
Signed-off-by: Sasha Levin