From: Sean Christopherson <seanjc@google.com>
To: Luka Absandze <absandze@amazon.de>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"sandipan.das@amd.com" <sandipan.das@amd.com>,
"tglx@kernel.org" <tglx@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86/pmu: Don't retry a counter whose config was rejected
Date: Fri, 18 Sep 2026 14:39:56 -0700 [thread overview]
Message-ID: <aq2vrDkgfPGeJ-wD@google.com> (raw)
In-Reply-To: <aq2ZCFXMDnUWwCuY@dev-dsk-absandze-1c-663c31a8.eu-west-1.amazon.com>
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.
prev parent reply other threads:[~2026-09-18 21:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 16:00 Luka Absandze
2026-09-18 16:16 ` Sean Christopherson
2026-09-18 20:21 ` Absandze, Luka
2026-09-18 21:39 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aq2vrDkgfPGeJ-wD@google.com \
--to=seanjc@google.com \
--cc=absandze@amazon.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sandipan.das@amd.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®