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, Mar 25, 2024, Michael Kelley wrote:
> >  static void setup_pcid(void)
> >  {
> > +	const struct x86_cpu_id *invlpg_miss_match;
> > +
> >  	if (!IS_ENABLED(CONFIG_X86_64))
> >  		return;
> > 
> >  	if (!boot_cpu_has(X86_FEATURE_PCID))
> >  		return;
> > 
> > -	if (x86_match_cpu(invlpg_miss_ids)) {
> > +	invlpg_miss_match = 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.

Enumerating broken PCID support to a guest is very arguably a hypervisor bug.
Hypervisors also lie to guest about FMS.  As KVM *user* with affected hardware
(home box), I would want the kernel to assume PCID works if X86_FEATURE_HYPERVISOR
is present.