Re: [PATCH v2 06/10] x86/mce: Convert multiple if () statements into a switch() statement

From: Dave Hansen
Date: Mon Oct 21 2024 - 20:17:45 EST


On 10/21/24 15:57, Sohil Mehta wrote:
> On 10/21/2024 11:40 AM, Luck, Tony wrote:
>>>> Intel model number allocation policies aren't necessarily sequential.
>>> Model numbers are assumed to be sequential at least within family 6.
>> Assumption can only be applied retroactively to simpler times. Looking
>> at the timelines and model numbers for pure-Atom, pure-Core, Hybrid,
>> and Xeon, they are somewhat jumbled.
>>
> Agreed. Using range checks within a family with extreme care and
> avoiding cross-family ones seems like the saner thing to do.
>
> Maybe everything in the future is enumerated and VFM checks would not be
> needed 🙂
>
> Trying to understand more, I have more questions than answers. With the
> introduction of Family 0x19, do we need to reevaluate some of the
> existing model checks?
>
> early_init_intel():
> if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> (c->x86 == 0x6 && c->x86_model >= 0x0e))
> set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
>
> It seems "constant_tsc" wouldn't show on Diamond rapids. Do we need it to?

We only have a handful of these and they're mostly for early family 6
things. I bet there's less than half a dozen.

Let's just list them in one of our match structures:

const u32 NOT_SUPPORTED = UINT_MAX; // or another special, invalid VFM
const u32 ALL_SUPPORTED = 0;

static const struct x86_cpu_id table[] __initconst = {
X86_MATCH_FAM(INTEL, 3, NOT_SUPPORTED),
X86_MATCH_FAM(INTEL, 4, NOT_SUPPORTED),
X86_MATCH_FAM(INTEL, 5, NOT_SUPPORTED),
X86_MATCH_FAM(INTEL, 6, INTEL_CORE_YONAH),
X86_MATCH_FAM(INTEL, 0xf, INTEL_P4_WHATEVER),
X86_MATCH_VEN(INTEL, ALL_SUPPORTED),
};

... and then use it like this:

m = x86_match_cpu(table);
// Non-Intel lands here:
if (!m)
return false;

if (VFM_MODEL(c->x86_vfm) >= m->driver_data)
return true;

return false;