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

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

[Zhang Rui]

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

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

[Zhang Rui]

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

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

[Guenter Roeck]

On 8/12/22 08:08, 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.
> 

So far I only got this e-mail (and I don't find any of the other patches
elsewhere either), and it looks like the hwmon mailing list was not copied
on any of the patches. Please copy the hwmon mailing list for all changes
in hwmon code.

Thanks,
Guenter

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

[Zhang Rui]

On Fri, 2022-08-12 at 09:09 -0700, Guenter Roeck wrote:
> On 8/12/22 08:08, 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.
> > 
> 
> So far I only got this e-mail (and I don't find any of the other
> patches
> elsewhere either), and it looks like the hwmon mailing list was not
> copied
> on any of the patches. Please copy the hwmon mailing list for all
> changes
> in hwmon code.

Hi, Guenter,

Thanks for the quick response.
Yeah, I'm checking this, it seems that all my patches sent with git
send-email is blocked, let me retry.

thanks,
rui
> 
> Thanks,
> Guenter

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

[Zhang Rui]

Hi, Ingo,

Thanks for reviewing this patch series.

On Sat, 2022-08-13 at 12:44 +0200, Ingo Molnar wrote:
> 
> * 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.

Sure, I will re-arrange this.


thanks,
rui

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

[Ingo Molnar]

* 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

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

[Zhang Rui]

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.

The patch series have been tested on Intel ICL/CLX servers, SKL/KBL/ADL
clients.

thanks,
-rui