Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected

Hanjun Guo
2026-01-12T11:19:11Z

On 2026/1/10 23:04, Feng Tang wrote:
> Hi Hanjun,
>
[...]
>>>
>>> It provides a global and straightforward view of the hierarchy of the
>>> processor and caches info of the platform, and from the offset info
>>> (the 3rd column), the child-parent relation could be checked.
>>>
>>> With this, the root cause of the original issue was pretty obvious,
>>> that there were some caches items missing which caused the issue when
>>> building up scheduler domain.
>>
>> Just a discussion, can we just dump the raw PPTT table via acpidump
>> in user space when we meet the problem? With the raw PPTT table, we
>> can go though the content to see if we have problems.
>
> Good point! We can use iasl to decode the PPTT table. And this dump
> is still useful as:
> * when enabling new silicon or new firmware (APCI tables), sometimes it
> can't make to boot to user space when the issue happens.
> * This dump shows the processor and cache items separately and cleanly,
> while the P[]/C[] index imply the numbers. In an 128 core product ARM
> sever, the print with this patch is about 500 line, while the acpidump
> is about 10,000 lines and harder to parse.

Thanks for the user case, it makes sense to me.

>
[...]
>>> /**
>>> * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
>>> * @table: Pointer to the head of the PPTT table
>>> @@ -565,6 +638,8 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
>>> }
>>> pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
>>> cpu, acpi_cpu_id);
>>> +
>>> + acpi_dump_pptt_table(table);
>>
>> I think it would be good to dump it as needed, as a debug feature.
>
> Makes sense to me. Should I add a kernel config option or a module
> parameter for it, or just change the pr_info to pr_debug (it's in
> a unlikely error path)?

PPTT driver can not be compiled as a module, I would like to add a
kernel config for it.

Thanks
Hanjun