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

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

[Xi Ruoyao]

Per the "Processor Specification Update" documentations referred by the
intel-microcode-20240312 release note, this microcode release has fixed
the issue for all affected models.

So don't disable INVLPG if the microcode is new enough.

Cc: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/all/168436059559.404.13934972543631851306.tip-bot2@tip-bot2/
Link: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20240312
Link: https://cdrdv2.intel.com/v1/dl/getContent/740518 # RPL042, rev. 13
Link: https://cdrdv2.intel.com/v1/dl/getContent/682436 # ADL063, rev. 24
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
---
 arch/x86/mm/init.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 679893ea5e68..a6a2f38c3999 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -279,6 +279,25 @@ static const struct x86_cpu_id invlpg_miss_ids[] = {
 	{}
 };
 
+/*
+ * INVLPG issue is fixed with intel-microcode-20240312 for all
+ * affected models.  This table is taken from the release note
+ * of this microcode release.
+ */
+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),
+	{}
+};
+
 static void setup_pcid(void)
 {
 	if (!IS_ENABLED(CONFIG_X86_64))
@@ -287,7 +306,8 @@ static void setup_pcid(void)
 	if (!boot_cpu_has(X86_FEATURE_PCID))
 		return;
 
-	if (x86_match_cpu(invlpg_miss_ids)) {
+	if (x86_match_cpu(invlpg_miss_ids) &&
+	    !x86_cpu_has_min_microcode_rev(invlpg_miss_fixed_ucode)) {
 		pr_info("Incomplete global flushes, disabling PCID");
 		setup_clear_cpu_cap(X86_FEATURE_PCID);
 		return;
-- 
2.44.0

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

[Dave Hansen]

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.

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

[Xi Ruoyao]

On Sun, 2024-03-24 at 11:29 -0700, Dave Hansen wrote:
> 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.

Hmm, I also thought there should be this thing but I couldn't find it...
Let me try again.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University