Re: [PATCH 1/4] ACPI / PPTT: Add a helper to fill a cpumask from a processor container

[James Morse <james.morse@arm.com>]

Hi Sudeep,

On 23/06/2025 14:21, Sudeep Holla wrote:
> On Thu, Jun 12, 2025 at 05:13:33PM +0000, James Morse wrote:
>> The PPTT describes CPUs and caches, as well as processor containers.
>> The ACPI table for MPAM describes the set of CPUs that can access an MSC
>> with the UID of a processor container.
>>
>> Add a helper to find the processor container by its id, then walk
>> the possible CPUs to fill a cpumask with the CPUs that have this
>> processor container as a parent.

>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> index 54676e3d82dd..aaf9b5a26d07 100644
>> --- a/drivers/acpi/pptt.c
>> +++ b/drivers/acpi/pptt.c
>> +
>> +/**
>> + * acpi_pptt_get_cpus_from_container() - Populate a cpumask with all CPUs in a
>> + *                                       processor containers
>> + * @acpi_cpu_id:	The UID of the processor container.
>> + * @cpus		The resulting CPU mask.
>> + *
>> + * Find the specified Processor Container, and fill @cpus with all the cpus
>> + * below it.
>> + *
>> + * Not all 'Processor' entries in the PPTT are either a CPU or a Processor
>> + * Container, they may exist purely to describe a Private resource. CPUs
>> + * have to be leaves, so a Processor Container is a non-leaf that has the
>> + * 'ACPI Processor ID valid' flag set.
>> + *
>> + * Return: 0 for a complete walk, or an error if the mask is incomplete.
>> + */
>> +int acpi_pptt_get_cpus_from_container(u32 acpi_cpu_id, cpumask_t *cpus)
>> +{

> Just noticed now that it is not used anywhere in the series. Can this be added
> along with the user later instead ?

T'was mentioned in the cover letter - I'll roll these into the series with the driver -
which will unfortunately give you more email. There is another pre-requisite series, which
made posting it like this was going to be easier for reviewers.

Do you have an opinion on how this should get merged?
The MPAM driver may need to go via tip if it has dependencies on resctrl, but also arm64
because it touches the arch code's __cpu_switch_to() path. Adding acpi and potentially
Greg's tree for cacheinfo makes this more complicated. I will probably defer the restrl
parts of the MPAM driver to remove one of these.


Thanks,

James