<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/acpi/pptt.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-03-14T19:34:38Z</updated>
<entry>
<title>ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent</title>
<updated>2023-03-14T19:34:38Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2023-03-08T11:26:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=91d7b60a65d9f71230ea09b86d2058a884a3c2af'/>
<id>urn:sha1:91d7b60a65d9f71230ea09b86d2058a884a3c2af</id>
<content type='text'>
Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
enabled to map PPTT once on the first invocation of acpi_get_pptt() and
never unmapped the same allowing it to be used at runtime with out the
hassle of mapping and unmapping the table. This was needed to fetch LLC
information from the PPTT in the cpuhotplug path which is executed in
the atomic context as the acpi_get_table() might sleep waiting for a
mutex.

However it missed to handle the case when there is no PPTT on the system
which results in acpi_get_pptt() being called from all the secondary
CPUs attempting to fetch the LLC information in the atomic context
without knowing the absence of PPTT resulting in the splat like below:

 | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164
 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
 | preempt_count: 1, expected: 0
 | RCU nest depth: 0, expected: 0
 | no locks held by swapper/1/0.
 | irq event stamp: 0
 | hardirqs last  enabled at (0): 0x0
 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40
 | softirqs last  enabled at (0): copy_process+0x61c/0x1b40
 | softirqs last disabled at (0): 0x0
 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1
 | Call trace:
 |  dump_backtrace+0xac/0x138
 |  show_stack+0x30/0x48
 |  dump_stack_lvl+0x60/0xb0
 |  dump_stack+0x18/0x28
 |  __might_resched+0x160/0x270
 |  __might_sleep+0x58/0xb0
 |  down_timeout+0x34/0x98
 |  acpi_os_wait_semaphore+0x7c/0xc0
 |  acpi_ut_acquire_mutex+0x58/0x108
 |  acpi_get_table+0x40/0xe8
 |  acpi_get_pptt+0x48/0xa0
 |  acpi_get_cache_info+0x38/0x140
 |  init_cache_level+0xf4/0x118
 |  detect_cache_attributes+0x2e4/0x640
 |  update_siblings_masks+0x3c/0x330
 |  store_cpu_topology+0x88/0xf0
 |  secondary_start_kernel+0xd0/0x168
 |  __secondary_switched+0xb8/0xc0

Update acpi_get_pptt() to consider the fact that PPTT is once checked and
is not available on the system and return NULL avoiding any attempts to
fetch PPTT and thereby avoiding any possible sleep waiting for a mutex
in the atomic context.

Fixes: 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
Reported-by: Aishwarya TCV &lt;aishwarya.tcv@arm.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Tested-by: Pierre Gondois &lt;pierre.gondois@arm.com&gt;
Cc: 6.0+ &lt;stable@vger.kernel.org&gt; # 6.0+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: PPTT: Update acpi_find_last_cache_level() to acpi_get_cache_info()</title>
<updated>2023-01-18T09:58:40Z</updated>
<author>
<name>Pierre Gondois</name>
<email>pierre.gondois@arm.com</email>
</author>
<published>2023-01-04T18:30:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bd500361a937c03a3da57178287ce543c8f3681b'/>
<id>urn:sha1:bd500361a937c03a3da57178287ce543c8f3681b</id>
<content type='text'>
acpi_find_last_cache_level() allows to find the last level of cache
for a given CPU. The function is only called on arm64 ACPI based
platforms to check for cache information that would be missing in
the CLIDR_EL1 register.
To allow populating (struct cpu_cacheinfo).num_leaves by only parsing
a PPTT, update acpi_find_last_cache_level() to get the 'split_levels',
i.e. the number of cache levels being split in data/instruction
caches.

It is assumed that there will not be data/instruction caches above a
unified cache.
If a split level consist of one data cache and no instruction cache
(or opposite), then the missing cache will still be populated
by default with minimal cache information, and maximal cpumask
(all non-existing caches have the same fw_token).

Suggested-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Signed-off-by: Pierre Gondois &lt;pierre.gondois@arm.com&gt;
Reviewed-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Acked-by: Rafael J. Wysocki  &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20230104183033.755668-6-pierre.gondois@arm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
</content>
</entry>
<entry>
<title>ACPI: PPTT: Remove acpi_find_cache_levels()</title>
<updated>2023-01-18T09:58:40Z</updated>
<author>
<name>Pierre Gondois</name>
<email>pierre.gondois@arm.com</email>
</author>
<published>2023-01-04T18:30:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fa4d566a605bc4cf32d69f16ef8cf9696635f75a'/>
<id>urn:sha1:fa4d566a605bc4cf32d69f16ef8cf9696635f75a</id>
<content type='text'>
acpi_find_cache_levels() is used at a single place and is short
enough to be merged into the calling function. The removal allows
an easier renaming of the calling function in the next patch.

Also reorder the local variables in the 'reversed Christmas tree'
order.

Signed-off-by: Pierre Gondois &lt;pierre.gondois@arm.com&gt;
Reviewed-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Acked-by: Rafael J. Wysocki  &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20230104183033.755668-5-pierre.gondois@arm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
</content>
</entry>
<entry>
<title>ACPI: PPTT: Leave the table mapped for the runtime usage</title>
<updated>2022-07-22T08:04:43Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2022-07-20T12:55:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0c80f9e165f8f9cca743d7b6cbdb54362da297e0'/>
<id>urn:sha1:0c80f9e165f8f9cca743d7b6cbdb54362da297e0</id>
<content type='text'>
Currently, everytime an information needs to be fetched from the PPTT,
the table is mapped via acpi_get_table() and unmapped after the use via
acpi_put_table() which is fine. However we do this at runtime especially
when the CPU is hotplugged out and plugged in back since we re-populate
the cache topology and other information.

However, with the support to fetch LLC information from the PPTT in the
cpuhotplug path which is executed in the atomic context, it is preferred
to avoid mapping and unmapping of the PPTT for every single use as the
acpi_get_table() might sleep waiting for a mutex.

In order to avoid the same, the table is needs to just mapped once on
the boot CPU and is never unmapped allowing it to be used at runtime
with out the hassle of mapping and unmapping the table.

Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;

--

Hi Rafael,

Sorry to bother you again on this PPTT changes. Guenter reported an issue
with lockdep enabled in -next that include my cacheinfo/arch_topology changes
to utilise LLC from PPTT in the CPU hotplug path.

Please ack the change once you are happy so that I can get it merged with
other fixes via Greg's tree.

Regards,
Sudeep

Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Link: https://lore.kernel.org/r/20220720-arch_topo_fixes-v3-2-43d696288e84@arm.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: Remove the unused find_acpi_cpu_cache_topology()</title>
<updated>2022-07-04T15:23:23Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2022-07-04T10:16:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7128af87c7f1c30cd6cebe0b012cc25872c689e2'/>
<id>urn:sha1:7128af87c7f1c30cd6cebe0b012cc25872c689e2</id>
<content type='text'>
The sole user of this find_acpi_cpu_cache_topology() was arm64 topology
which is now consolidated into the generic arch_topology without the need
of this function.

Drop the unused function find_acpi_cpu_cache_topology().

Link: https://lore.kernel.org/r/20220704101605.1318280-22-sudeep.holla@arm.com
Cc: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Reported-by: Ionela Voinescu &lt;ionela.voinescu@arm.com&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
</content>
</entry>
<entry>
<title>ACPI: PPTT: Use table offset as fw_token instead of virtual address</title>
<updated>2022-07-04T15:22:27Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2022-07-04T10:15:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0d4c331af4d169de26186170010c7b7acd49f266'/>
<id>urn:sha1:0d4c331af4d169de26186170010c7b7acd49f266</id>
<content type='text'>
There is need to use the cache sharing information quite early during
the boot before the secondary cores are up and running. The permanent
memory map for all the ACPI tables(via acpi_permanent_mmap) is turned
on in acpi_early_init() which is quite late for the above requirement.

As a result there is possibility that the ACPI PPTT gets mapped to
different virtual addresses. In such scenarios, using virtual address as
fw_token before the acpi_permanent_mmap is enabled results in different
fw_token for the same cache entity and hence wrong cache sharing
information will be deduced based on the same.

Instead of using virtual address, just use the table offset as the
unique firmware token for the caches. The same offset is used as
ACPI identifiers if the firmware has not set a valid one for other
entries in the ACPI PPTT.

Link: https://lore.kernel.org/r/20220704101605.1318280-2-sudeep.holla@arm.com
Cc: linux-acpi@vger.kernel.org
Tested-by: Ionela Voinescu &lt;ionela.voinescu@arm.com&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
</content>
</entry>
<entry>
<title>topology: Represent clusters of CPUs within a die</title>
<updated>2021-10-15T09:25:15Z</updated>
<author>
<name>Jonathan Cameron</name>
<email>Jonathan.Cameron@huawei.com</email>
</author>
<published>2021-09-24T08:51:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c5e22feffdd736cb02b98b0f5b375c8ebc858dd4'/>
<id>urn:sha1:c5e22feffdd736cb02b98b0f5b375c8ebc858dd4</id>
<content type='text'>
Both ACPI and DT provide the ability to describe additional layers of
topology between that of individual cores and higher level constructs
such as the level at which the last level cache is shared.
In ACPI this can be represented in PPTT as a Processor Hierarchy
Node Structure [1] that is the parent of the CPU cores and in turn
has a parent Processor Hierarchy Nodes Structure representing
a higher level of topology.

For example Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus.

+-----------------------------------+                          +---------+
|  +------+    +------+             +--------------------------+         |
|  | CPU0 |    | cpu1 |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   +----+    L3     |         |         |
|  +------+    +------+   cluster   |    |    tag    |         |         |
|  | CPU2 |    | CPU3 |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   |    |    L3     |         |         |
|  +------+    +------+             +----+    tag    |         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |   L3    |
                                                               |   data  |
+-----------------------------------+                          |         |
|  +------+    +------+             |    +-----------+         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             +----+    L3     |         |         |
|                                   |    |    tag    |         |         |
|  +------+    +------+             |    |           |         |         |
|  |      |    |      |             |    +-----------+         |         |
|  +------+    +------+             +--------------------------+         |
+-----------------------------------|                          |         |
+-----------------------------------|                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   +----+    L3     |         |         |
|  +------+    +------+             |    |    tag    |         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |   +-----------+          |         |
|  +------+    +------+             |   |           |          |         |
|                                   |   |    L3     |          |         |
|  +------+    +------+             +---+    tag    |          |         |
|  |      |    |      |             |   |           |          |         |
|  +------+    +------+             |   +-----------+          |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |  +-----------+           |         |
|  +------+    +------+             |  |           |           |         |
|                                   |  |    L3     |           |         |
|  +------+    +------+             +--+    tag    |           |         |
|  |      |    |      |             |  |           |           |         |
|  +------+    +------+             |  +-----------+           |         |
|                                   |                          +---------+
+-----------------------------------+

That means spreading tasks among clusters will bring more bandwidth
while packing tasks within one cluster will lead to smaller cache
synchronization latency. So both kernel and userspace will have
a chance to leverage this topology to deploy tasks accordingly to
achieve either smaller cache latency within one cluster or an even
distribution of load among clusters for higher throughput.

This patch exposes cluster topology to both kernel and userspace.
Libraried like hwloc will know cluster by cluster_cpus and related
sysfs attributes. PoC of HWLOC support at [2].

Note this patch only handle the ACPI case.

Special consideration is needed for SMT processors, where it is
necessary to move 2 levels up the hierarchy from the leaf nodes
(thus skipping the processor core level).

Note that arm64 / ACPI does not provide any means of identifying
a die level in the topology but that may be unrelate to the cluster
level.

[1] ACPI Specification 6.3 - section 5.2.29.1 processor hierarchy node
    structure (Type 0)
[2] https://github.com/hisilicon/hwloc/tree/linux-cluster

Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Tian Tao &lt;tiantao6@hisilicon.com&gt;
Signed-off-by: Barry Song &lt;song.bao.hua@hisilicon.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20210924085104.44806-2-21cnbao@gmail.com
</content>
</entry>
<entry>
<title>ACPI: tables: PPTT: Populate cache-id if provided by firmware</title>
<updated>2021-06-07T13:55:02Z</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2021-06-01T12:17:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7ca1a8014d860d23001605f63c1402f1092a58d5'/>
<id>urn:sha1:7ca1a8014d860d23001605f63c1402f1092a58d5</id>
<content type='text'>
ACPI 6.4 adds a 'cache id' to the PPTT Cache Type Structure.

Copy this property across into the cacheinfo leaf when it was
provided by firmware.

This value gets exposed to userspace as:
/sys/devices/system/cpu/cpu*/cache/index*/id.

See the "Cache IDs" section of Documentation/x86/resctrl.rst.

Co-authored-by: Joey Gouly &lt;joey.gouly@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Joey Gouly &lt;joey.gouly@arm.com&gt;
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: PPTT: Consistently use unsigned int as parameter type</title>
<updated>2020-01-07T10:46:36Z</updated>
<author>
<name>Tian Tao</name>
<email>tiantao6@huawei.com</email>
</author>
<published>2019-12-30T11:56:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=643956e61ced913a2bbdcf2c95f3d03026b39d1c'/>
<id>urn:sha1:643956e61ced913a2bbdcf2c95f3d03026b39d1c</id>
<content type='text'>
The fourth parameter 'level' of function 'acpi_find_cache_level()' is
a signed interger, but its caller 'acpi_find_cache_node()' passes that
parameter an unsigned interger.

Make the paramter type inconsistency go away.

Signed-off-by: Tian Tao &lt;tiantao6@huawei.com&gt;
Signed-off-by: Xiongfeng Wang &lt;wangxiongfeng2@huawei.com&gt;
[ rjw: Subject/changelog ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI/PPTT: Add support for ACPI 6.3 thread flag</title>
<updated>2019-08-12T11:59:15Z</updated>
<author>
<name>Jeremy Linton</name>
<email>jeremy.linton@arm.com</email>
</author>
<published>2019-08-08T20:40:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bbd1b70639f785a970d998f35155c713f975e3ac'/>
<id>urn:sha1:bbd1b70639f785a970d998f35155c713f975e3ac</id>
<content type='text'>
ACPI 6.3 adds a flag to the CPU node to indicate whether
the given PE is a thread. Add a function to return that
information for a given linux logical CPU.

Signed-off-by: Jeremy Linton &lt;jeremy.linton@arm.com&gt;
Reviewed-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Reviewed-by: Robert Richter &lt;rrichter@marvell.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
</entry>
</feed>
