kvm_pmu_handle_event() re-arms the reprogram bit for every failed reprogram, on the assumption that the failure is transient and a later refresh will succeed. That is true for contention, e.g. the -EBUSY from x86_reserve_hardware(), but not for a configuration the host PMU driver rejects outright. A rejected config can never succeed on retry, so the counter is reprogrammed on every PMU refresh for as long as the guest leaves it enabled, and every attempt fails the same way. Skip the re-arm for -EINVAL, one of the errnos the x86 PMU drivers use for a config they will never accept. Note this becomes reachable on AMD only with the patch linked below, which starts rejecting the Merge event (PMCxFFF) a guest programs as part of a Large Increment per Cycle pair; on Intel it is already reachable today via the INTEL_FIXED_VLBR_EVENT check in intel_pmu_hw_config(), where the config is likewise a function of fixed guest state and can never start being accepted. Link: https://lore.kernel.org/all/20260916123315.89042-1-absandze@amazon.de/ Signed-off-by: Luka Absandze --- arch/x86/kvm/pmu.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index a7d60c8785cd..b9945a6256ed 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -680,8 +680,14 @@ void kvm_pmu_handle_event(struct kvm_vcpu *vcpu) * reprogram bit, i.e. opportunistically try again on the next * PMU refresh. Don't make a new request as doing so can stall * the guest if reprogramming repeatedly fails. + * + * -EINVAL means the event's config was rejected outright and + * can never succeed on retry, so don't re-arm; the guest can + * still do so itself by rewriting the event selector. */ - if (reprogram_counter(pmc)) + int r = reprogram_counter(pmc); + + if (r && r != -EINVAL) set_bit(pmc->idx, pmu->reprogram_pmi); } -- 2.47.3