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

["Chen, Zide" <zide.chen@intel.com>]

On 10/30/2026 6:55 AM, Jim Mattson wrote:
> On Thu, Oct 29, 2026 at 10:45 AM Chen, Zide <zide.chen@intel.com> 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?