Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002

[Mark Rutland <mark.rutland@arm.com>]

On Fri, Oct 16, 2026 at 01:00:13PM +0000, Tomohiro Misono (Fujitsu) wrote:
> > Subject: Re: [PATCH v2 3/4] perf: arm_pmu: Add workaround for FUJITSU-MONAKA Erratum E#030002
> > 
> > On Fri, Oct 16, 2026 at 07:00:47PM +0900, Tomohiro Misono wrote:
> > > FUJITSU-MONAKA Erratum E#030002 affects FUJITSU-MONAKA CPU.
> > >
> > > On affected FUJITSU-MONAKA CPUs, after a PMU event counter is
> > > stopped at a value just before overflow, an overflow might still
> > > be incorrectly detected, resulting interrupt storm in some case.
> > >
> > > For example, if the following conditions are met:
> > >   1) Running perf to count an event in user space only
> > >   2) The event can also occur in kernel space
> > >   3) The counter value is set just before the overflow
> > >      (when using the -F option, initial counter value is -1)
> > >
> > > when the kernel is about to return to user space after enabling
> > > the count, an overflow interrupt is incorrectly triggered by an
> > > event that occurred in kernel space. Since the counter value is
> > > not updated (correctly), the interrupt handler does nothing and
> > > returns with the same condition. This leads to another wrong interrupt
> > > and results in an interrupt storm and eventually a softlockup.
> > 
> > I don't fully understand this.
> > 
> > Surely the relevant PMOVS{CLR,SET}[n] bit set as if the counter n
> > overflowed?
> > 
> > If that bit is set, the handler will certainly do *something*.
> > 
> > If that bit is not set, the interrupt shouldn't be asserted at all. When
> > does it get de-asserted?
> 
> Sorry, my explanation wasn't clear. The interrupt will be de-asserted
> as usual.

I'm trying to work out which of the following happens due to the
erratum:

(a) When the erratum occurs, the HW sets a bit in PMOVS*. An overflow
    interrupt is asserted because PMOVS* is non-zero. The overflow
    handler will see that bit was set in PMOVS*. Clearing PMOVS*
    de-asserts the interrupt as usual.

(b) When the erratum occurs, the HW does not set a bit in PMOVS*, and
    asserts an overflow interrupt even if PMOVS* is clear.  The overflow
    handler might not see a bit set in PMOVS*.

(c) Something else.

Can you pleaes confirm what HW does with PMOVS* when the erratum occurs?
I assume (a), but you haven't explicitly stated that so far.

> The problem is that armpmu_event_set_period() will not update the counter
> value if, for example, the counter is -1. Therefore, false overflow detection will continue.
> With this patch, armpmu_event_set_period() will force the counter to -6 so that
> false overflow detection won't occur in the kernel, since the maximum event
> count at a time is 5.

I expected that were this to occur a number of times in quick
succession, the core perf code would throttle the event, and adjust the
period.

I am presumably missing some detail that prevents that.

I assume you've seen the issue in practice? i.e. you've actucally
triggered this with the perf tool on real hardware?

Mark.