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 1:23 PM, Jim Mattson wrote:
> On Fri, Oct 30, 2026 at 10:20 AM Chen, Zide <zide.chen@intel.com> wrote:
>>
>>
>>
>> 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?
> 
> That seems reasonable to me, as long as the architectural misbehavior
> is documented in Documentation/virt/kvm/x86/errata.rst.

How about add something like this to errata.rst:

IA32_PERF_GLOBAL_STATUS_RESET
-----------------------------
To reduce VM-exits to performance-critical paths, KVM passes through
writes to IA32_PERF_GLOBAL_STATUS_RESET (0x390) in mediated PMU mode,
even if the MSR has bits that are not supported by KVM.  Consequently,
KVM does not inject #GP if the guest writes bits that are valid in
hardware but unvirtualized by KVM.