Messages in this thread | | | Date | Fri, 29 Mar 2024 18:23:57 +0100 | From | Borislav Petkov <> | 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
| |