Re: [PATCH] KVM: x86/pmu: Don't retry a counter whose config was rejected

[Sandipan Das]

On 19-09-2026 03:09, Sean Christopherson wrote:
> On Fri, Sep 18, 2026, Luka Absandze wrote:
>> On 2026-09-18 09:16, Sean Christopherson wrote:
>>> Hmm, would it instead make more sense to explicitly check for -EBUSY?  -EINVAL
>>> isn't the only fatal error code.
>>>
>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>> index a7d60c8785cd..5296ee8f32af 100644
>>> --- a/arch/x86/kvm/pmu.c
>>> +++ b/arch/x86/kvm/pmu.c
>>> @@ -681,7 +681,7 @@ void kvm_pmu_handle_event(struct kvm_vcpu *vcpu)
>>>                  * PMU refresh.  Don't make a new request as doing so can stall
>>>                  * the guest if reprogramming repeatedly fails.
>>>                  */
>>> -               if (reprogram_counter(pmc))
>>> +               if (reprogram_counter(pmc) == -EBUSY)
>>>                         set_bit(pmc->idx, pmu->reprogram_pmi);
>>>         }
>>>
>>> Though I guess one could argue -ENOMEM is also transient?
>>
>> I had contemplated this, but could not convince myself at a glance that
>> perf and KVM agreed on what constituted a transient error.
>> I have now concluded I was seeing ghosts :)
>>
>>> E.g. this? (completely untested)
>>> [diff]
>>
>> Tested against the fault described in the linked patch and selftests on
>> AMD Zen 3 (although I don't think there's much coverage in this regard).
>>
>> If no other objections, would you be fine with taking the diff you
>> provided into the tree or would you prefer a v2?
> 
> Go ahead and send a v2, I want to see what Sashiko thinks.

>From a quick glance, it seems EBUSY and ENOMEM might just be sufficient.
The former occurs when a pinned event cannot be created cause all counters
are exhausted and the latter due to various event and context struct
related alloc failures.