From: Ravi Bangoria <ravi.bangoria@amd.com>
To: Jim Mattson <jmattson@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Manali Shukla <manali.shukla@amd.com>,
Sandipan Das <sandipan.das@amd.com>,
Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"James Clark" <james.clark@linaro.org>,
Thomas Gleixner <tglx@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Yosry Ahmed <yosry@kernel.org>,
<linux-perf-users@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH] perf/amd/ibs: Clear stale IBS_{FETCH|OP}_CTL in perf_ibs_start() with CTL2[Dis]
Date: Tue, 13 Oct 2026 09:32:59 +0530 [thread overview]
Message-ID: <3685289e-beae-42f1-a574-44c6a64a6b00@amd.com> (raw)
In-Reply-To: <20261009202812.2149137-1-jmattson@google.com>
>> + if (config & perf_ibs->valid_mask) {
>> + ctl = config;
>> + while (delay-- && ctl & perf_ibs->valid_mask) {
>> + udelay(1);
>> + rdmsrq(hwc->config_base, ctl);
>> + }
>> + }
>
> This loop will time out when running in NMI context:
>
> perf_ibs_handle_irq() ->
> perf_event_overflow() ->
> __perf_event_overflow() ->
> __perf_event_account_interrupt() ->
> perf_event_throttle_group() ->
> perf_event_throttle() ->
> perf_ibs_stop() ->
> perf_ibs_stop_dis()
>
> Should the loop just be skipped when in_nmi()?
Right. However, I'm planning to move the polling to ->start() and
also fix ->stop() with:
---
@@ -980,6 +980,14 @@ static void perf_ibs_stop_dis(struct perf_event *event, int flags)
rdmsrq(hwc->config_base, config);
config &= ~perf_ibs->valid_mask;
+
+ /*
+ * Clear the Val bit otherwise ->start() will unnecessarily
+ * wait for 50us.
+ */
+ if (in_nmi())
+ wrmsrq(hwc->config_base, config);
+
perf_ibs_event_update(perf_ibs, event, &config);
hwc->state |= PERF_HES_UPTODATE;
---
>> + /* Catch delayed NMIs which arrives after disabling IBS PMUs. */
>> + if (ibs_caps & IBS_CAPS_DIS) {
>> + rdmsrq(perf_ibs->msr2, ctl2);
>> + if (ctl2 & perf_ibs->disable_mask) {
>> + rdmsrq(perf_ibs->msr, ctl);
>> + if (ctl & perf_ibs->valid_mask) {
>> + ctl &= ~(perf_ibs->enable_mask &
>> + perf_ibs->valid_mask);
>
> enable_mask and valid_mask are disjoint. Should '&' be '|'?
Yes, will fix this.
>> + wrmsrq(perf_ibs->msr, ctl);
>> + return 1;
>> + }
>> + return 0;
>> + }
>> +
>
> [...]
>
>> if (WARN_ON_ONCE(!event))
>
> With IBS_CAPS_DIS, we are now treating CTL2[Dis] as authoritative on the
> question of "is IBS idle." However, on the BSP after S3 resume
Yes, the syscore->resume() path needs to be fixed as well.
> or on any
> LPU after an AE #VMEXIT from an SEV-ES/SNP guest with IBS virtualization
> enabled, CTL2[Dis] will be reset to 0 and may no longer be authoritative.
KVM should save/restore host IBS MSRs when vIBS is enabled.
>> I think the intention is, host IBS should be disabled (could be from
>> CTL2[Dis]) before running VMRUN. But I'll confirm with the HW team.
Hardware checks the effective IBS op and fetch enables in VMRUN to a
SEV-SE/SEV-SNP guest. Effective enable being CTL[En] && !CTL2[Dis].
(This will be documented in the upcoming APM)
> Another question for the HW team: can the hardware set CTL[Val], or change
> CTL in any other way, after CTL2[Dis] has been set? The answer may
> obviate the need for the 50us poll.
Once IBS is disabled via CTL2, the hardware will not capture any new
samples, so the CTL register should remain unchanged. However, the
50us polling window is still necessary to account for potential NMI
latency.
Thanks,
Ravi
prev parent reply other threads:[~2026-10-13 4:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 23:48 Jim Mattson
2026-10-09 3:49 ` Ravi Bangoria
2026-10-09 20:28 ` Jim Mattson
2026-10-13 4:02 ` Ravi Bangoria [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=3685289e-beae-42f1-a574-44c6a64a6b00@amd.com \
--to=ravi.bangoria@amd.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jmattson@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=manali.shukla@amd.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sandipan.das@amd.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=yosry@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®