linux-kernel - Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo

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: Fri, 29 Mar 2024 18:23:57 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tony Luck <tony.luck@...el.com>
Cc: "x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to
 struct cpuinfo_x86

On Fri, Mar 29, 2024 at 09:46:25AM -0700, Tony Luck wrote:
> I think you are talking about a range of models that all belong to
> the same family (rather than steppings in the same model).

Either. Depending on what you're tracking. If the majority of your
feature tests want to determine whether you're running on the same set
of hw features which belong to a model determined by a single or
multiple model numbers, then you need to track that.

On Intel you have a single model number determining that set of hw
features.

On AMD you have s range of model numbers and there can be differences
too.

Seldom we pay attention to steppings but it is not unheard of. We have
had an incremented stepping denoting a hw bug fix in the past.

> History of Intel model number allocations apparently looks like
> we just throw a dart in the general area of a block of unused
> model numbers :-)

Don't say that. The guy who's assigning the numbers and keeps track of
what he's given to which team, will be mad at you. :-P

> I'm glad I don't have to keep track of groups of hex numbers like that.

Depends on how you model it. Setting a X86_FEATURE_ZEN<n> for each works
like a charm.

> My patch doesn't help with this, but doesn't prevent you from doing
> a switch (c->x86_model).  If that list of model number ranges shows
> up more than twice you could add a helper that converts that list to
> a #define AMD_ZEN2 to make the code clearer.

Haven't needed such stunts yet and I hope I won't ever.

> So keep the "V" in the common code. Maybe one of the other x86
> vendors will want to have #define names for their CPU models
> some day.

Right.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette