Re: [PATCH] arm_mpam: Account for a MBWU overflow before reading the counter value

[Ping Li <leeonion.muyu@gmail.com>]

From: leeonion.muyu@gmail.com

Hi Ben,

Thanks for taking a look.

> Is the a theoretical fix or has this been observed in practice?

Not observed in practice. My hardware team was reviewing the software
overflow and NRDY checking logic with me, and we found this while
walking through the code together.

> Based on this, for MBWU you should only see NRDY set in the
> MAX_NRDY_USEC after a change of monitor settings. At such a reset
> the VALUE is reset to 0. Are you seeing or potentially seeing an
> overflow in this window of time?

I agree. Our starting assumption was IHI0099B.d 6.2.1 RGKWNB - that on
a settings update the monitor VALUE field keeps counting using the new
criteria without automatically resetting to 0. But as you point out,
looking at the reconfiguration path in write_msmon_ctl_flt_vals(),
the driver deliberately writes VALUE to 0 as part of the IDGYLF
sequence, so the accumulated count is discarded there and even a
31-bit monitor cannot overflow within the NRDY window after a
reconfiguration. The overflow and NRDY cannot collide.

My apologies - there was a second trigger in my original analysis
that the commit message failed to mention: any error reading the
counter value after the status bit has been cleared loses the
accounting the same way, and mpam_msmon_read() does not retry
non-EBUSY errors. For a MPAM_F capable MSC, mpam_msc_read_mbwu_l()
and mpam_read_monsel_reg() go through the PCC mailbox and can return
-ETIMEDOUT or -EIO on transport errors. So I believe the patch still
provides protection against this failure path - it moves the
accounting to the point where the status bit has been read but not
yet cleared, and it is a no-op in the normal path.

Thanks,
Ping