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

[Sean Christopherson <seanjc@google.com>]

On Mon, Apr 08, 2024, Michael Kelley wrote:
> From: Dave Hansen <dave.hansen@intel.com> Sent: Thursday, April 4, 2024 11:09 AM
> > 
> > On 4/4/24 10:48, Michael Kelley wrote:
> > > I agree one could argue that it is a hypervisor bug to present PCID to 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, at least
> > > for Hyper-V, I don't know. What's the real impact of running with PCID while
> > > the flaw is still present? I don’t know the history here ...
> > 
> > There's a chance that INVLPG will appear ineffective.
> > 
> > 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.
> 
> Xi Ruoyao's patch identifies these errata:  RPL042 and ADL063.  In the links
> to the documents Xi provided, both of these errata have the following
> statement in the Errata Details section:
> 
>     This erratum does not apply in VMX non-root operation.  It applies only
>     when PCIDs are enabled and either in VMX root operation or outside
>     VMX operation.
> 
> I don't have deep expertise on the terminology here, but this sounds
> like it is saying the erratum doesn’t 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 probably
makes sense to have KVM advertise support if PCID is available in hardware, even
if PCID is disabled by the host kernel.