[PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor overflow handling

[Ben Horgan]

Hi Zeng,

On 10/25/25 09:45, Zeng Heng wrote:
> Hi Ben,
> 
> On 2025/10/23 0:17, Ben Horgan wrote:
>>>
>>> Also fix the handling of overflow amount calculation. There's no need to
>>> subtract mbwu_state->prev_val when calculating overflow_val.
>>
>> Why not? Isn't this the pre-overflow part that we are missing from the
>> running count?
>>
> 
> The MSMON_MBWU register accumulates counts monotonically forward and
> would not automatically cleared to zero on overflow.
> 
> The overflow portion is exactly what mpam_msmon_overflow_val() computes,
> there is no need to additionally subtract mbwu_state->prev_val.

Yes, I now see you are correct. The 'correction' ends up holding
(counter size) * (number of overflows) and the current value of the
counter plus this gives you the bandwidth use up until now.

> 
>>>
>>> Signed-off-by: Zeng Heng <zengheng4 at huawei.com>
>>> ---
>>>   drivers/resctrl/mpam_devices.c | 8 +++++---
>>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/
>>> mpam_devices.c
>>> index 0dd048279e02..06f3ec9887d2 100644
>>> --- a/drivers/resctrl/mpam_devices.c
>>> +++ b/drivers/resctrl/mpam_devices.c
>>> @@ -1101,7 +1101,8 @@ static void __ris_msmon_read(void *arg)
>>>       clean_msmon_ctl_val(&cur_ctl);
>>>       gen_msmon_ctl_flt_vals(m, &ctl_val, &flt_val);
>>>       config_mismatch = cur_flt != flt_val ||
>>> -              cur_ctl != (ctl_val | MSMON_CFG_x_CTL_EN);
>>> +             (cur_ctl & ~MSMON_CFG_x_CTL_OFLOW_STATUS) !=
>>> +             (ctl_val | MSMON_CFG_x_CTL_EN);
>>
>> This only considers 31 bit counters. I would expect any change here to
>> consider all lengths of counter. Also, as the overflow bit is no longer
>> reset due to the config mismatch it needs to be reset somewhere else.
> 
> Yes, overflow bit needs to be cleared somewhere. I try to point out in
> the next patch mail.

I had misunderstood before but the current code in the series doesn't
make use of overflow bit and just relies on prev_val > now. Using
overflow status does give us a bit more lee-way for overflowing so is a
useful enhancement.

> 
> Best Regards,
> Zeng Heng
> 
> 
Thanks,

Ben