linux-kernel - Re: [PATCH v3 04/29] ACPI / PPTT: Add a helper to fill a cpumask from a cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cc81b3f4-5736-4c11-894a-b37cf1c7c0a8@arm.com>
Date: Thu, 6 Nov 2025 16:18:16 +0000
From: Ben Horgan <ben.horgan@....com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>,
 Jeremy Linton <jeremy.linton@....com>
Cc: James Morse <james.morse@....com>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
 D Scott Phillips OS <scott@...amperecomputing.com>,
 carl@...amperecomputing.com, lcherian@...vell.com,
 bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
 baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
 Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
 dfustini@...libre.com, amitsinght@...vell.com,
 David Hildenbrand <david@...hat.com>, Dave Martin <dave.martin@....com>,
 Koba Ko <kobak@...dia.com>, Shanker Donthineni <sdonthineni@...dia.com>,
 fenghuay@...dia.com, baisheng.gao@...soc.com, Rob Herring <robh@...nel.org>,
 Rohit Mathew <rohit.mathew@....com>, Rafael Wysocki <rafael@...nel.org>,
 Len Brown <lenb@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Hanjun Guo <guohanjun@...wei.com>, Sudeep Holla <sudeep.holla@....com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Danilo Krummrich <dakr@...nel.org>, Gavin Shan <gshan@...hat.com>
Subject: Re: [PATCH v3 04/29] ACPI / PPTT: Add a helper to fill a cpumask from
 a cache_id

Hi Jonathan, Jeremy,

(Replying for James as I'll post the next version of this series.)

On 10/24/25 15:22, Jonathan Cameron wrote:
> On Wed, 22 Oct 2025 07:58:36 -0500
> Jeremy Linton <jeremy.linton@....com> wrote:
> 
>> Hi,
>>
>> This is largely looking pretty solid, but..
>>
>>
>> On 10/17/25 1:56 PM, James Morse wrote:
>>> MPAM identifies CPUs by the cache_id in the PPTT cache structure.
>>>
>>> The driver needs to know which CPUs are associated with the cache.
>>> The CPUs may not all be online, so cacheinfo does not have the
>>> information.
>>>
>>> Add a helper to pull this information out of the PPTT.
>>>
>>> CC: Rohit Mathew <Rohit.Mathew@....com>
>>> Signed-off-by: James Morse <james.morse@....com>
>>> Reviewed-by: Sudeep Holla <sudeep.holla@....com>
>>> Tested-by: Fenghua Yu <fenghuay@...dia.com>
>>> ---
[...]
>>
>> Is the core acpi definition in actbl2.h correct? Shouldn't it be 
>> something along the lines of:
>>
>> struct acpi_pptt_cache_v1 {
>>   struct acpi_subtable_header header;
>>   u16 reservedd;
>>   u32 flags;
>>   u32 next_level_of_cache;
>>   u32 size;
>>   u32 number_of_sets;
>>   u8 associativity;
>>   u8 attributes;
>>   u16 lines_size;
>>   u32 cache_id;
>> }
>>
>>
>> Then that solves the detection of the additional field problem correctly 
>> because the length (24 vs 28) of the subtable then tells you which 
>> version your dealing with. (and goes back to why much of this is coded 
>> to use ACPI_ADD_PTR rather than structure+ logic.)
>>
> 
> Do we want to deal with arguing the change in ACPICA? 
> I fully agree that it would be much nicer if that didn't use this weird
> bits of structures approach :(  

For the moment I've added:

struct acpi_pptt_cache_v1_full {
	struct acpi_pptt_cache		f;
	struct acpi_pptt_cache_v1	extra;
} __packed;

in drivers/acpi/pptt.c
A stop gap but the length can be used to check for field presence and
you can avoid some ACPI_ADD_PTR usages.

> 
> https://github.com/acpica/acpica/blob/master/source/include/actbl2.h#L3497
> is where this is coming from.
> 
> Maybe can do it in parallel. Rafael, what do you think is best way forwards
> with this?
> 
> Jonathan
Thanks,

Ben