linux-kernel - Re: [PATCH] x86/cpu: Add two Intel CPU model numbers

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] [day] [month] [year] [list]

Message-ID: <aAHz1tru8GT9ET9j@gmail.com>
Date: Fri, 18 Apr 2025 08:40:22 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Luck, Tony" <tony.luck@...el.com>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"Hansen, Dave" <dave.hansen@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86/cpu: Add two Intel CPU model numbers


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Feb 12, 2025 at 04:09:11PM +0000, Luck, Tony wrote:
> > >> +/* Family 19 */ +#define INTEL_PANTHERCOVE_X IFM(19, 0x01) /* Diamond
> > >> Rapids */
> > >
> > > Is it intentional that this is not INTEL_DIAMONDRAPIDS_X like
> > > Sapphire/Emerald/Granite ?
> > 
> > Andrew,
> > 
> > PeterZ wants to name based on core, not SoC (at least for mono-core CPUs ... this
> > doesn't work for hybrid).  Argue with him.
> 
> Argh :-)
> 
> So yeah, its a trainwreck.
> 
> We used to use uarch, and that worked until skylake.
> 
> I'm not sure what exactly we continued as, but Kaby Lake was a Skylake
> uarch.
> 
> The Atoms are uarch and still are, they weren't messed up.
> 
> But if you want to do DMR as PANTERCOVE then SPR should've been
> GOLDENCOVE and we didn't do that either.
> 
> 
> Also, since DMR is the direct continuation of GRANITERAPIDS, it should
> also come below it.
> 
> Therefore, I'll concur with Andy that this is all highly irregular and
> would propose we do the below.
> 
> Isn't the only reason we're doing a new Family because we can out of
> module number space? It's not magically different from Fam6.

Mind sending this with a changelog, or at least a SOB? :)

Thanks,

	Ingo