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

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

On 11/2/2026 5:37 PM, Yosry Ahmed wrote:
>>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>>> index 38c7a4fa1007..3849b3f5234a 100644
>>>> --- a/arch/x86/kvm/pmu.c
>>>> +++ b/arch/x86/kvm/pmu.c
>>>> @@ -862,6 +862,8 @@ int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, struct
>>>> msr_data *msr_info)
>>>>         switch (msr) {
>>>>         case MSR_CORE_PERF_GLOBAL_STATUS:
>>>>         case MSR_AMD64_PERF_CNTR_GLOBAL_STATUS:
>>>> +               if (msr_info->host_initiated)
>>>> +                       pmu->global_status &= ~pmu->global_status_rsvd;
>>>>
>>>> The underlying issue still requires proper mutual exclusion between
>>>> Intel PT and mediated vPMU, which I think can be addressed separately.
>>>
>>> Or maybe handle the host PT while the guest is running? Not sure if
>>> that would be correct.
>>
>> Since KVM switches APIC LVTPC in guest context, it seems difficult to
>> correctly handle host PT PMIs while the guest is running.
> 
> One hacky way to do it is to make perf_guest_handle_mediated_pmi()
> handle host PT before calling into KVM. This doesn't completely stop
> the guest from seeing the bit tho. Also, I think we may have no way of
> finding out if we still need to inject a PMI into the guest for a
> different reason or not :/

Right, and the host perf subsystem doesn't know which GLOBAL_STATUS bits
it is supposed to handle.

The hardware-assisted perfmon_mask solution seems like a clean way to
avoid this problem. :)

And I think if Intel PT virtualization is re-enabled at some point,
addressing the mutual exclusion issue would probably be necessary
regardless.

>>
>> I guess Intel PT virtualization could be re-enabled sooner or later, and
>> addressing the exclusion issue would be a must at that point anyway.