Received-SPF: pass (google.com: domain of linux-kernel+bounces-136096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 9 Apr 2024 01:43:39 +0000
In-Reply-To: <SN6PR02MB4157FDA1C431A92873AA1AAED4002@SN6PR02MB4157.namprd02.prod.outlook.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240324190503.116160-1-xry111@xry111.site> <SN6PR02MB41576028614CB7FE9A11EBEBD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
 <Zg7S5dk3J4Zc82nj@google.com> <d1cc1f7c-9df0-4e3c-88ae-aedcd556ba95@citrix.com>
 <Zg7jLn-lV55Yh6mH@google.com> <SN6PR02MB415717D76F71C023A574841ED43C2@SN6PR02MB4157.namprd02.prod.outlook.com>
 <f8df14f3-ae6a-4e08-927a-7a7c2ebe8352@intel.com> <SN6PR02MB4157FDA1C431A92873AA1AAED4002@SN6PR02MB4157.namprd02.prod.outlook.com>
Message-ID: <ZhSdSwqUprIgLVtr@google.com>
Subject: Re: [PATCH v2] x86/mm: Don't disable INVLPG if "incomplete Global
 INVLPG flushes" is fixed by microcode
From: Sean Christopherson <seanjc@google.com>
To: Michael Kelley <mhklinux@outlook.com>
Cc: Dave Hansen <dave.hansen@intel.com>, Andrew Cooper <andrew.cooper3@citrix.com>, 
	Xi Ruoyao <xry111@xry111.site>, Dave Hansen <dave.hansen@linux.intel.com>, 
	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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 08, 2024, Michael Kelley wrote:
> From: Dave Hansen <dave.hansen@intel.com> Sent: Thursday, April 4, 2024 1=
1:09 AM
> >=20
> > On 4/4/24 10:48, Michael Kelley wrote:
> > > I agree one could argue that it is a hypervisor bug to present PCID t=
o the guest
> > > in this situation. It's a lot cleaner to not have a guest be checking=
 FMS and
> > > microcode versions. But whether that's practical in the real world, a=
t least
> > > for Hyper-V, I don't know. What's the real impact of running with PCI=
D while
> > > the flaw is still present? I don=E2=80=99t know the history here ...
> >=20
> > There's a chance that INVLPG will appear ineffective.
> >=20
> > The bad sequence would go something like this: The kernel does the
> > INVLPG on a global mapping.  Later, when switching PCIDs, the TLB entry
> > mysteriously reappears.  No PCIDs switching means no mysterious
> > reappearance.
>=20
> Xi Ruoyao's patch identifies these errata:  RPL042 and ADL063.  In the li=
nks
> to the documents Xi provided, both of these errata have the following
> statement in the Errata Details section:
>=20
>     This erratum does not apply in VMX non-root operation.  It applies on=
ly
>     when PCIDs are enabled and either in VMX root operation or outside
>     VMX operation.
>=20
> I don't have deep expertise on the terminology here, but this sounds
> like it is saying the erratum doesn=E2=80=99t apply in a guest VM.  Or am=
 I
> misunderstanding?

Huh.  My read of that is the same as yours.  If that's the case, then it pr=
obably
makes sense to have KVM advertise support if PCID is available in hardware,=
 even
if PCID is disabled by the host kernel.