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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <152465d1-08cc-898e-8ed7-9b603faaabc5@huawei.com>
Date: Mon, 12 Jan 2026 19:19:07 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: Feng Tang <feng.tang@...ux.alibaba.com>
CC: "Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
	Jeremy Linton <jeremy.linton@....com>, James Morse <james.morse@....com>,
	Joanthan Cameron <Jonathan.Cameron@...wei.com>, Sudeep Holla
	<sudeep.holla@....com>, <linux-acpi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected

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