Re: [PATCH v2 11/16] KVM: x86/pmu: Emulate the GLOBAL_STATUS_SET and GLOBAL_INUSE MSRs

[Jim Mattson]

On Fri, Oct 30, 2026 at 10:20 AM Chen, Zide <zide.chen@xxxxxxxxx> wrote:
>
>
>
> On 10/30/2026 6:55 AM, Jim Mattson wrote:
> > On Thu, Oct 29, 2026 at 10:45 AM Chen, Zide <zide.chen@xxxxxxxxx> wrote:
> >> On 10/28/2026 4:24 PM, Jim Mattson wrote:
> > [ ... ]
> >>> As I pointed out in patch 04/16, we can't pass through the PMU global
> >>> controls unless their reserved bits match hardware.
> >>
> >> Totally agree. Then the handling of bit 55 breaks this rule as well.
> >>
> >> if (vmx_pt_mode_is_host_guest())
> >>         pmu->global_status_rsvd &= ~GLOBAL_STATUS_TRACE_TOPAPMI;
> >>
> >> Always intercepting GLOBAL_OVF_CTRL and GLOBAL_STATUS_SET can solve this
> >> problem, but it may impair guest performance, especially for nested.
> >>
> >> Instead, I'd propal to have separate reserved masks:
> >> - pmu->global_status_rsvd: unchanged, strictly tracking virtualized
> >> guest state and preserving live migration validation.
> >> - pmu->global_status_{clr,set}_rsvd: unmasking all architecturally valid
> >> hardware bits for the corresponding MSRs on v4+.
> >>
> >> Any bits allowed by hardware but unvirtualized by KVM are
> >> scrubbed/filtered in intel_mediated_pmu_{put,load}().
> >
> > That is a terrible proposal. MSR bits that vanish at unpredictable
> > times?!? No. If an MSR contains bits that aren't virtualized, that MSR
> > can't be passed through. Full stop.
>
> OK, I agree. I will intercept GLOBAL_STATUS_SET (0x391) and remove the
> nested_vmx_merge_msr_bitmaps() for it.
>
> However, I propose we keep GLOBAL_OVF_CTRL (0x390) passed through, even
> though its reserved bits don't match hardware. Since it is
> write-1-to-clear, it cannot manufacture unvirtualized state or leak host
> data.
>
> The only divergence is the lack of a #GP if the guest writes an
> unvirtualized but hardware-valid bit. If we want to eliminate this
> behavior by intercepting it, it will force an additional VM-exit on
> every single guest PMI.
>
> What do you think?

That seems reasonable to me, as long as the architectural misbehavior
is documented in Documentation/virt/kvm/x86/errata.rst.