linux-kernel - Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

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:   Thu, 27 Sep 2018 16:49:18 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        kan.liang@...ux.intel.com, mingo@...hat.com, len.brown@...el.com,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

On Thu, 27 Sep 2018, Peter Zijlstra wrote:
> On Wed, Aug 08, 2018 at 07:14:52AM +0200, Thomas Gleixner wrote:
> 
> > We have that for the big cores as well:
> > 
> > #define INTEL_FAM6_HASWELL_CORE         0x3C
> > #define INTEL_FAM6_HASWELL_X            0x3F
> > #define INTEL_FAM6_HASWELL_ULT          0x45
> > #define INTEL_FAM6_HASWELL_GT3E         0x46
> > 
> > Why would we treat ATOM differently? It's all the same scheme:
> > 
> > SILVERMONT_CLIENT  	0x37	     Baytrail, Valleyview
> > SILVERMONT_SERVER	0x40	     Avaton, Rangely
> > 
> > and on goldmont it's not any different.
> > 
> > We really want one scheme for both Core and ATOM and not randomly picked
> > different ones. For the kernel (aside of some peripheral stuff) the most
> > interesting information is the UARCH plus the extra features which are
> > enabled on a particular SoC.
> > 
> > The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2
> > variants are in fact CLIENT/SERVER and the comment in the header file, that
> > there is no better name, is just silly.
> 
> OK, I spend a lot of time googling various things and came up with the
> below. TL;DR:
> 
> /* "Small Core" Processors (Atom) */
> 
> #define INTEL_FAM6_ATOM_BONNELL		0x1C /* Diamondville, Pineview */
> #define INTEL_FAM6_ATOM_BONNELL_MID	0x26 /* Silverthorne, Lincroft */
> 
> #define INTEL_FAM6_ATOM_SALTWELL	0x36 /* Cedarview */
> #define INTEL_FAM6_ATOM_SALTWELL_MID	0x27 /* Penwell */
> #define INTEL_FAM6_ATOM_SALTWELL_TABLET	0x35 /* Cloverview */
> 
> #define INTEL_FAM6_ATOM_SILVERMONT	0x37 /* Bay Trail, Valleyview */
> #define INTEL_FAM6_ATOM_SILVERMONT_X	0x4D /* Avaton, Rangely */
> #define INTEL_FAM6_ATOM_SILVERMONT_MID	0x4A /* Merriefield */
> 
> #define INTEL_FAM6_ATOM_AIRMONT		0x4C /* Cherry Trail, Braswell */
> #define INTEL_FAM6_ATOM_AIRMONT_MID	0x5A /* Moorefield */
> 
> #define INTEL_FAM6_ATOM_GOLDMONT	0x5C /* Apollo Lake */
> #define INTEL_FAM6_ATOM_GOLDMONT_X	0x5F /* Denvertor */
> #define INTEL_FAM6_ATOM_GOLDMONT_PLUS	0x7A /* Gemini Lake */

Thanks for doing that!

> ---
> Subject: x86/cpu: Sanitize FAM6_ATOM naming
> From: Peter Zijlstra <peterz@...radead.org>
> Date: Tue, 7 Aug 2018 10:17:27 -0700
> 
> Going primarily by:
> 
>   https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Silvermont_microarchitecture
> 
> with additional information gleaned from other related pages; notably:
> 
>  - Bonnell shrink was called Saltwell
>  - Moorefield is the Merriefield refresh which makes it Airmont
> 
> The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
> 
> Cc: x86@...nel.org
> Cc: mingo@...hat.com
> Cc: ak@...ux.intel.com
> Cc: tglx@...utronix.de
> Cc: dave.hansen@...ux.intel.com
> Cc: len.brown@...el.com
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>

Which way do we route that?

Thanks,

	tglx