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:   Wed, 8 Aug 2018 07:14:52 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andi Kleen <ak@...ux.intel.com>
cc:     Peter Zijlstra <peterz@...radead.org>,
        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 Tue, 7 Aug 2018, Andi Kleen wrote:

> > Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs
> > with that Fam/Model combination are:
> > 
> >  - Apollo Lake
> >  - Broxton (has two platforms: Morganfield and Willowtrail)
> 
> Right pick one. The others are the same for software purposes
> and can be handled in the same way.

Pick one is really not a good choice. 

> > It's even worse with Silvermont.
> > 
> > So no, the interesting information is the UARCH and the variant of that,
> 
> With Uarch you mean the core uarch?  That doesn't really work for
> something like Silvermont or Goldmont.
> 
> > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names
> 
> Right your scheme totally doesn't work on Silvermont because there
> are multiple client variants.

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.

Thanks,

	tglx