Re: [PATCH 0/7] x86/topology: Improve CPUID.1F handling

From: Ingo Molnar <mingo@kernel.org>
To: Zhang Rui <rui.zhang@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-hwmon@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, corbet@lwn.net, fenghua.yu@intel.com,
	jdelvare@suse.com, linux@roeck-us.net, len.brown@intel.com
Subject: Re: [PATCH 0/7] x86/topology: Improve CPUID.1F handling
Date: Sat, 13 Aug 2022 12:44:55 +0200	[thread overview]
Message-ID: <YveAp8W3zZliQXrq@gmail.com> (raw)
In-Reply-To: <20220812164144.30829-1-rui.zhang@intel.com>

* Zhang Rui <rui.zhang@intel.com> wrote:

> On Intel AlderLake-N platforms where there are Ecores only, the Ecore
> Module topology is enumerated via CPUID.1F Module level, which has not
> been supported by Linux kernel yet.
> 
> This exposes two issues in current CPUID.1F handling code.
> 1. Linux interprets the Module id bits as package id and erroneously
>    reports a multi module system as a multi-package system.
> 2. Linux excludes the unknown Module id bits from the core_id, and results
>    in duplicate core_id’s shown in a package after the first issue solved.
> 
> Plus that, a third problem is observed on Intel Hybrid ADL-S/P platforms.
> The return value of CPUID.1F SMT level EBX (number of siblings) differs on
> Pcore CPUs and Ecore CPUs, and results in inconsistent smp_num_siblings
> value based on the Pcore/Ecore CPU enumeration order. This could bring
> some potential issues although we have not observed any functionalities
> issues so far.
> 
> Patch 1/7 and 2/7 fix the first two issues. And at the same time, it
> reveals a reality that the core_id could be sparse on platforms with
> CPUID.1F support.
> Patch 3/7 improves coretemp driver code to be able to handle sparse core
> id, which is the only driver that uses core_id as array index and run on
> platforms with CPUID.1F support.
> 
> Patch 4/7 to 7/7 propose a fix for the third problem and update the
> related Documents.

Yeah, so patch 3/7 probably needs to come first - otherwise there's a 
window for bisection breakage.

Thanks,

	Ingo