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: <SJ1PR11MB60838D20A4EE6FC26A544E0DFCFE2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 14 Feb 2025 17:17:51 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, Peter Zijlstra
	<peterz@...radead.org>
CC: "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.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

> > 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.
>
> Right. That was the primary motivation.
>
> But the new scheme should also make a little more logical sense. The
> family numbers are supposed to move up at a steady rate and also
> separate desktop and server.

Nope. There isn't a commitment to put desktop/server into different families.

There's an upcoming patch for a CPU in family 18, when I post it I'll
add a big fat comment telling people not to extrapolate from two
data points with one CPU in each of family 18 and 19.

It doesn't seem like there would be any use case for that. I don't
envision code that looks like:

	if (family == 18) {
		// modern desktop/mobile stuff
	} else if (family == 19) {
		// modern Xeon stuff
	} else {
		// Legacy
	}

I'm fine with Peter's patch to move Diamond Rapids up just after Granite Rapids.
That will help make it clear that family numbers are no longer important. Just
a way to extend the "model" space beyond 8 bits.

> Or maybe we'll realize we miss all the fun of family 6 and just start
> shoving everything as models in family 19 randomly instead. ;)

After the early models in family 6 where Linux tried to check ranges of models,
it became clear that X86_FEATURE bits from other CPUID leaves was the right
way to do such checks. It shouldn't matter at all if new CPUs come out randomly
assigned to different families.

-Tony