Re: [PATCH v2] perf/x86: Move event pointer setup earlier in x86_pmu_enable()

[Peter Zijlstra]

On Fri, Mar 13, 2026 at 06:23:41AM -0700, Breno Leitao wrote:
> On Thu, Mar 12, 2026 at 10:53:59AM +0800, Mi, Dapeng wrote:
> > On 3/12/2026 4:40 AM, Peter Zijlstra wrote:
> > > Subject: x86/perf: Make sure to program the counter value for stopped events on migration
> > > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > > Date: Wed Mar 11 21:29:14 CET 2026
> > >
> > > Both Mi Dapeng and Ian Rogers noted that not everything that sets HES_STOPPED
> > > is required to EF_UPDATE. Specifically the 'step 1' loop of rescheduling
> > > explicitly does EF_UPDATE to ensure the counter value is read.
> > >
> > > However, then 'step 2' simply leaves the new counter uninitialized when
> > > HES_STOPPED, even though, as noted above, the thing that stopped them might not
> > > be aware it needs to EF_RELOAD -- since it didn't EF_UPDATE on stop.
> > >
> > > One such location that is affected is throttling, throttle does pmu->stop(, 0);
> > > and unthrottle does pmu->start(, 0); possibly restarting an uninitialized counter.
> > >
> > > Fixes: a4eaf7f14675 ("perf: Rework the PMU methods")
> > > Reported-by: Dapeng Mi <dapeng1.mi@xxxxxxxxxxxxxxx>
> > > Reported-by: Ian Rogers <irogers@xxxxxxxxxx>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> > > ---
> > >  arch/x86/events/core.c |    4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > --- a/arch/x86/events/core.c
> > > +++ b/arch/x86/events/core.c
> > > @@ -1374,8 +1374,10 @@ static void x86_pmu_enable(struct pmu *p
> > >
> > >  			cpuc->events[hwc->idx] = event;
> > >
> > > -			if (hwc->state & PERF_HES_ARCH)
> > > +			if (hwc->state & PERF_HES_ARCH) {
> > > +				static_call(x86_pmu_set_period)(event);
> > >  				continue;
> > > +			}
> > >
> > >  			/*
> > >  			 * if cpuc->enabled = 0, then no wrmsr as
> >
> > LGTM.
> >
> > Reviewed-by: Dapeng Mi <dapeng1.mi@xxxxxxxxxxxxxxx>
> 
> Thank you for the patch and the discussion. To confirm my understanding:
> this patch should be applied on top of my v2 series to fully resolve the
> issue, correct?
> 
> If so, would you prefer that I include both patches together in a single
> series, or are you fine with them as-is?

Yeah, I've got then in queue/perf/urgent and once the robot is done
chewing on them, I'll push them out into tip.

Thanks!