Received-SPF: pass (google.com: domain of linux-kernel+bounces-112805-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <6cb0333cb0e60aa9f7e914af26c605d075f90d61.camel@xry111.site>
Subject: Re: [PATCH] x86/mm: Don't disable INVLPG if "incomplete Global
 INVLPG flushes" is fixed by microcode
From: Xi Ruoyao <xry111@xry111.site>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>, Peter Zijlstra
 <peterz@infradead.org>,  Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar
 <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin"
 <hpa@zytor.com>, x86@kernel.org, linux-kernel@vger.kernel.org
Date: Mon, 25 Mar 2024 02:31:37 +0800
In-Reply-To: <319db7f3-7ce1-4096-a168-e5869c7a42f6@intel.com>
References: <20240324170630.76084-1-xry111@xry111.site>
	 <319db7f3-7ce1-4096-a168-e5869c7a42f6@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.0 
Precedence: bulk
MIME-Version: 1.0

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.=C2=A0 This table is taken from the release note
> > + * of this microcode release.
> > + */
>=20
> That comment is much more changelog material than code comment material.
>=20
> > +static const struct x86_cpu_desc invlpg_miss_fixed_ucode[] =3D {
> > +	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),
> > +	{}
> > +};
>=20
> Why is this listing individual steppings?=C2=A0 That seems nuts when the
> issue affects *all* steppings or at least the invlpg_miss_ids[] table
> says it affects all steppings.
>=20
> The right way to do this is to take the existing table:
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_MATCH(INTEL_FAM6_ALDERLA=
KE=C2=A0=C2=A0 ),
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_MATCH(INTEL_FAM6_ALDERLA=
KE_L ),
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_MATCH(INTEL_FAM6_ATOM_GR=
ACEMONT ),
>=20
> and simply add the fix version:
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_WHATEVER(INTEL_FAM6_ALDE=
RLAKE,=C2=A0	=C2=A0 0x034),
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_WHATEVER(INTEL_FAM6_ALDE=
RLAKE_L,=C2=A0	=C2=A0 0x432),
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEL_WHATEVER(INTEL_FAM6_ATOM=
_GRACEMONT, 0x015),
>=20
> Then you do:
>=20
> 	c =3D x86_match_cpu(invlpg_miss_ids);
> 	if (boot_cpu_data.microcode >=3D c->data)
> 		return 0; // no mitiagtion
> 	// affected, do mitigation
>=20
> Then there's *one* table listing each model once and no steppings.=C2=A0 =
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.

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