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

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]

Date:   Sun, 14 Aug 2022 01:10:51 +0800
From:   Zhang Rui <rui.zhang@...el.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-hwmon@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        corbet@....net, fenghua.yu@...el.com, jdelvare@...e.com,
        linux@...ck-us.net, len.brown@...el.com
Subject: Re: [PATCH 0/7] x86/topology: Improve CPUID.1F handling

Hi, Ingo,

Thanks for reviewing this patch series.

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