Received-SPF: pass (google.com: domain of linux-kernel+bounces-116529-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Michael Kelley <mhklinux@outlook.com>
To: Xi Ruoyao <xry111@xry111.site>, Dave Hansen <dave.hansen@linux.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" <x86@kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, Dexuan Cui <decui@microsoft.com>
Subject: RE: [PATCH v2] x86/mm: Don't disable INVLPG if "incomplete Global
 INVLPG flushes" is fixed by microcode
Thread-Topic: [PATCH v2] x86/mm: Don't disable INVLPG if "incomplete Global
 INVLPG flushes" is fixed by microcode
Thread-Index: AQHafh5br9v5ziibjkOOzawG3mO/srFH4YWA
Date: Mon, 25 Mar 2024 04:57:33 +0000
Message-ID:
 <SN6PR02MB41576028614CB7FE9A11EBEBD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240324190503.116160-1-xry111@xry111.site>
In-Reply-To: <20240324190503.116160-1-xry111@xry111.site>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?3Qf6+0DWtLWbLIQBEqJrJWXeilJECvT4HRA7gEyDkhiFIos8zVtjcw2Kfk5k?=
 =?us-ascii?Q?JH6sVwez0INUO2rbL739OfVIjZQnhazL0YOo14qKIo0bDrRJfG6UuKoLhlJv?=
 =?us-ascii?Q?v0soYDD7d8xxoaBNCKi7AeXaXf7ZbR/zY9iHsdwvwNJ6/J3sm4cCDwO2Z0z7?=
 =?us-ascii?Q?GsokiujFZxCi1ubJJv0rKO1dRg2OqDKD52zGu3afvEmw8Um/i/XuFMsp5liG?=
 =?us-ascii?Q?VEh3aZf1mHLfnJjWHqFn2pvZDwK1KVOoWIeEK0HbD8kr5/IzjcBSBz5ns1AT?=
 =?us-ascii?Q?lnrtubyVqHv+AeJWZTPAur67acDbftwkqeot17/SiaOrJlnlKjMv3vKeVlm3?=
 =?us-ascii?Q?L3mxRN7JLrA+sh8gSt9Kf46EV2NghG6qsX7paIpu3pClLu3kEPWGQogHevxl?=
 =?us-ascii?Q?y+Oo3P4QM+wvXCNGuNfASk5eHih3wBho0pZXrhehUZUVz/LweaG7S3kjSLWJ?=
 =?us-ascii?Q?MduhPlMmd7P/LSLMXut8ATRtxzzNVOKEeg9SNfhMAIfNYTdH5aGFi5LUOwRh?=
 =?us-ascii?Q?5/aOsNXp6LdEDve5hjt61GKZWkNky03Uwu+Fh8ZRuq4/m7SF26O4NPpQYVDK?=
 =?us-ascii?Q?jVY1phGxGKWLlKV7wjbiiYHtzS6ptAlCVeOn3MaSmvnJTMhYn3Us4mFmZX7R?=
 =?us-ascii?Q?q1pBlQ16UHJM/+8hotiVqfiQ3DFA4yehWtvYiDd+nnHce9X74jRk0nyb1/tv?=
 =?us-ascii?Q?w8gMvLZi0d/DobaIYYjeOoJF68z4EjKExvJ58BoJiNWo70Jf9w79AnORy7Gl?=
 =?us-ascii?Q?UGp+sr0fQOv0YpaO0dT/YgwwEFD3EhSnw/FS/U33a+N6CC2vZ06Ro+1RvBfn?=
 =?us-ascii?Q?S7gFnmKZYACbu2+4UsIVGWxJkOym68n6vVYh+L0C3oOHsslFOkUDakDyj1IG?=
 =?us-ascii?Q?JeahU8yvZk5o74+SNFD+ntDvR+kGJbfxqCHOJ+3jLzSDtyL9itQEkaQYLPh/?=
 =?us-ascii?Q?a3gPBPgbpLW/kGs0oRy7uMxdXbLw80mPBrYKigKrO9cxXxwHVjCYDBTFKip4?=
 =?us-ascii?Q?rybd1et57PxW9M5PwikAwjB71vllhNwKuDvb36tWq6hoqYYappTMr+ZX3GV9?=
 =?us-ascii?Q?IxNulrpONePRM+Ghg1go7lsn1R5s99GmO3jTLcTLgRevHUI8KK+9KO5pqvCZ?=
 =?us-ascii?Q?6/OO6LPVqd3PFsYbECJ63312xgfz6R+qW4Xj7LvVz35pTa1PSfchbH61VWyg?=
 =?us-ascii?Q?XiJd3ZzZzC+DSUc4RE4LfsebWqpZPrJ9Ne3aaw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 722fa4a4-5f39-4f44-1fad-08dc4c88156f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2024 04:57:33.8268
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR02MB7301

From: Xi Ruoyao <xry111@xry111.site> Sent: Sunday, March 24, 2024 12:05 PM
>=20
> 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.
>=20
> So don't disable INVLPG if the microcode is new enough.
>=20
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Xi Ruoyao <xry111@xry111.site>
> ---
>  arch/x86/mm/init.c | 32 ++++++++++++++++++++------------
>  1 file changed, 20 insertions(+), 12 deletions(-)
>=20
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 679893ea5e68..c52be4e66e44 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -261,33 +261,41 @@ static void __init probe_page_size_mask(void)
>  	}
>  }
>=20
> -#define INTEL_MATCH(_model) { .vendor  =3D X86_VENDOR_INTEL,	\
> -			      .family  =3D 6,			\
> -			      .model =3D _model,			\
> -			    }
> +#define INTEL_MATCH(_model, _fixed_microcode)	\
> +    { .vendor		=3D X86_VENDOR_INTEL,	\
> +      .family		=3D 6,			\
> +      .model		=3D _model,		\
> +      .driver_data	=3D _fixed_microcode,	\
> +    }
> +
>  /*
>   * INVLPG may not properly flush Global entries
> - * on these CPUs when PCIDs are enabled.
> + * on these CPUs when PCIDs are enabled and the
> + * microcode is not updated to fix the issue.
>   */
>  static const struct x86_cpu_id invlpg_miss_ids[] =3D {
> -	INTEL_MATCH(INTEL_FAM6_ALDERLAKE   ),
> -	INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
> -	INTEL_MATCH(INTEL_FAM6_ATOM_GRACEMONT ),
> -	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE  ),
> -	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P),
> -	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S),
> +	INTEL_MATCH(INTEL_FAM6_ALDERLAKE,	0x34),
> +	INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L,	0x432),
> +	INTEL_MATCH(INTEL_FAM6_ATOM_GRACEMONT,	0x15),
> +	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE,	0x122),
> +	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P,	0x4121),
> +	INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S,	0x34),
>  	{}
>  };
>=20
>  static void setup_pcid(void)
>  {
> +	const struct x86_cpu_id *invlpg_miss_match;
> +
>  	if (!IS_ENABLED(CONFIG_X86_64))
>  		return;
>=20
>  	if (!boot_cpu_has(X86_FEATURE_PCID))
>  		return;
>=20
> -	if (x86_match_cpu(invlpg_miss_ids)) {
> +	invlpg_miss_match =3D x86_match_cpu(invlpg_miss_ids);
> +	if (invlpg_miss_match &&
> +	    invlpg_miss_match->driver_data > boot_cpu_data.microcode) {
>  		pr_info("Incomplete global flushes, disabling PCID");
>  		setup_clear_cpu_cap(X86_FEATURE_PCID);
>  		return;

As noted in similar places where microcode versions are
checked, hypervisors often lie to guests about microcode versions.
For example, see comments in bad_spectre_microcode().  I
know Hyper-V guests always see the microcode version as
0xFFFFFFFF (max u32 value).  So in a Hyper-V guest the above
code will always leave PCID enabled.

Maybe the above should have a check for running on a
hypervisor and always disable PCID without checking the
microcode version.  That's the safe approach, though there are
other similar cases like bad_spectre_microcode() that take
the unsafe approach when running as a guest.  I don't know
what's best here .....

Michael