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

[Dave Hansen]

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;