Re: [PATCH] x86/mm: Don't disable INVLPG if "incomplete Global INVLPG flushes" is fixed by microcode

From: Dave Hansen
Date: Sun Mar 24 2024 - 14:29:34 EST


On 3/24/24 10:06, Xi Ruoyao wrote:
> +/*
> + * INVLPG issue is fixed with intel-microcode-20240312 for all
> + * affected models. This table is taken from the release note
> + * of this microcode release.
> + */

That comment is much more changelog material than code comment material.

> +static const struct x86_cpu_desc invlpg_miss_fixed_ucode[] = {
> + INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE, 2, 0x34),
> + INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE, 5, 0x34),
> + INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE_L, 3, 0x432),
> + INTEL_CPU_DESC(INTEL_FAM6_ALDERLAKE_L, 4, 0x432),
> + INTEL_CPU_DESC(INTEL_FAM6_ATOM_GRACEMONT, 0, 0x15),
> + INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE, 1, 0x122),
> + INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_P, 2, 0x4121),
> + INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_P, 3, 0x4121),
> + INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_S, 2, 0x34),
> + INTEL_CPU_DESC(INTEL_FAM6_RAPTORLAKE_S, 5, 0x34),
> + {}
> +};

Why is this listing individual steppings? That seems nuts when the
issue affects *all* steppings or at least the invlpg_miss_ids[] table
says it affects all steppings.

The right way to do this is to take the existing table:

INTEL_MATCH(INTEL_FAM6_ALDERLAKE ),
INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
INTEL_MATCH(INTEL_FAM6_ATOM_GRACEMONT ),

and simply add the fix version:

INTEL_WHATEVER(INTEL_FAM6_ALDERLAKE, 0x034),
INTEL_WHATEVER(INTEL_FAM6_ALDERLAKE_L, 0x432),
INTEL_WHATEVER(INTEL_FAM6_ATOM_GRACEMONT, 0x015),

Then you do:

c = x86_match_cpu(invlpg_miss_ids);
if (boot_cpu_data.microcode >= c->data)
return 0; // no mitiagtion
// affected, do mitigation

Then there's *one* table listing each model once and no steppings. I
thought there's another example of this _somewhere_ but I couldn't find
it in two minutes of grepping.