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

[Zhang Rui <rui.zhang@intel.com>]

Resend with x86 mailing list.

On Fri, 2022-08-12 at 23:08 +0800, Zhang Rui 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.
> 
> 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
> and
> large 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.
> 
> The patch series have been tested on Intel ICL/CLX servers,
> SKL/KBL/ADL
> clients.
> 
> thanks,
> -rui