public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Feng Tang <feng.tang@linux.alibaba.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	James Morse <james.morse@arm.com>,
	Joanthan Cameron <Jonathan.Cameron@huawei.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ACPI/PPTT: Check total CPU numbers when a CPU can't be found in PPTT table
Date: Fri, 16 Jan 2026 13:52:37 +0000	[thread overview]
Message-ID: <aWpCpecZr7o0qIw2@bogus> (raw)
In-Reply-To: <20260116072943.26322-1-feng.tang@linux.alibaba.com>

On Fri, Jan 16, 2026 at 03:29:43PM +0800, Feng Tang wrote:
> There was a bug that kernel printed error message:
> " ACPI PPTT: PPTT table found, but unable to locate core 1 (1)"
> and later on the kernel met issues when building up scheduler domain.
> 
> Debug showed the kernel actually brought up all 8 CPUs successfully
> (MADT and other table worked fine), while the PPTT table was broken
> as it only had 4 CPUs in total.
> 
> Add check for number of CPU of PPTT table against system CPU number,
> and warn if they are not equal, to help debugging similar issues.
> 
> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
> ---
> Changelog:
> 
>   v3
>   * Only check the number of CPUs in PPTT table againt system
>     CPU count when error happens, instead of dump all the CPU/cache
> 	entries (Sudeep/Rafael)
> 
>   v2
>   * rebase againt 6.19 and refine the commit log
> 
>  drivers/acpi/pptt.c | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index de5f8c018333..9958c3961001 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -529,6 +529,43 @@ static void acpi_pptt_warn_missing(void)
>  	pr_warn_once("No PPTT table found, CPU and cache topology may be inaccurate\n");
>  }
>  
> +static void pptt_verify_cpu_count(struct acpi_table_header *table_hdr)
> +{
> +	struct acpi_subtable_header *entry;
> +	unsigned long end;
> +	struct acpi_pptt_processor *cpu;
> +	u8 len;
> +	int nr_pptt_cpus = 0;
> +	static bool checked;
> +
> +	if (checked)
> +		return;
> +
> +	end = (unsigned long)table_hdr + table_hdr->length;
> +	entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
> +				sizeof(struct acpi_table_pptt));
> +
> +	while ((unsigned long)entry + sizeof(struct acpi_pptt_processor) <= end) {
> +		len = entry->length;
> +		if (!len) {
> +			pr_warn("Invalid zero length subtable\n");
> +			return;
> +		}
> +
> +		cpu = (struct acpi_pptt_processor *)entry;
> +		entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry, len);
> +		if (cpu->header.type == ACPI_PPTT_TYPE_PROCESSOR &&
> +		    (cpu->flags & ACPI_PPTT_ACPI_LEAF_NODE))
> +			nr_pptt_cpus++;
> +	}
> +
> +	if (nr_pptt_cpus != num_possible_cpus())

This is going to be tricky. I recall some config option that sets all
`NR_CPUS` as possible. In short it will break if that is enabled.

> +		pr_warn("The number of CPUs (%d) in PPTT table doesn't match system's CPU count (%d)!\n",
> +			nr_pptt_cpus, num_possible_cpus());
> +
> +	checked = true;
> +}
> +
>  /**
>   * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
>   * @table: Pointer to the head of the PPTT table
> @@ -565,6 +602,9 @@ 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);

I was expecting the above log will be improved to just say possible mismatch
with cpu count.

> +
> +	/* Check whether PPTT table's CPU count match with system count */
> +	pptt_verify_cpu_count(table);

Today it is a request to check the CPU count; tomorrow it will be something
else in the PPTT. Where do we draw the line on PPTT validation in the kernel?
These issues ultimately need to be fixed in firmware, and the firmware
should not depend on the kernel to precisely identify what is wrong in
the PPTT tables.

-- 
Regards,
Sudeep

  reply	other threads:[~2026-01-16 13:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16  7:29 [PATCH v3] ACPI/PPTT: Check total CPU numbers when a CPU can't be found in PPTT table Feng Tang
2026-01-16 13:52 ` Sudeep Holla [this message]
2026-01-20  1:42   ` Feng Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWpCpecZr7o0qIw2@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=feng.tang@linux.alibaba.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox