linux-kernel - Re: [PATCH v2] arm64/mpam: Clean MBWU monitor overflow bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f4518f80-8e17-e622-fbe6-e20a7d1c85fc@huawei.com>
Date: Mon, 3 Nov 2025 11:47:03 +0800
From: Zeng Heng <zengheng4@...wei.com>
To: Ben Horgan <ben.horgan@....com>, <james.morse@....com>
CC: <amitsinght@...vell.com>, <baisheng.gao@...soc.com>,
	<baolin.wang@...ux.alibaba.com>, <carl@...amperecomputing.com>,
	<catalin.marinas@....com>, <dakr@...nel.org>, <dave.martin@....com>,
	<david@...hat.com>, <dfustini@...libre.com>, <fenghuay@...dia.com>,
	<gregkh@...uxfoundation.org>, <gshan@...hat.com>, <guohanjun@...wei.com>,
	<jeremy.linton@....com>, <jonathan.cameron@...wei.com>, <kobak@...dia.com>,
	<lcherian@...vell.com>, <lenb@...nel.org>, <linux-acpi@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<lpieralisi@...nel.org>, <peternewman@...gle.com>, <quic_jiles@...cinc.com>,
	<rafael@...nel.org>, <robh@...nel.org>, <rohit.mathew@....com>,
	<scott@...amperecomputing.com>, <sdonthineni@...dia.com>,
	<sudeep.holla@....com>, <tan.shaopeng@...itsu.com>, <will@...nel.org>,
	<xhao@...ux.alibaba.com>, <wangkefeng.wang@...wei.com>,
	<sunnanyong@...wei.com>
Subject: Re: [PATCH v2] arm64/mpam: Clean MBWU monitor overflow bit

Hi Ben,

On 2025/10/30 17:52, Ben Horgan wrote:
> Hi Zeng,
> 
> On 10/29/25 07:56, Zeng Heng wrote:
>> 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.
>>
>> Before invoking write_msmon_ctl_flt_vals(), the overflow bit of the
>> MSMON_MBWU register must first be read to prevent it from being
>> inadvertently cleared by the write operation.
>>
>> Finally, use the overflow bit instead of relying on counter wrap-around
>> to determine whether an overflow has occurred, that avoids the case where
>> a wrap-around (now > prev_val) is overlooked. So with this, prev_val no
>> longer has any use and remove it.
>>
>> CC: Ben Horgan <ben.horgan@....com>
>> Signed-off-by: Zeng Heng <zengheng4@...wei.com>
>> ---
>>   drivers/resctrl/mpam_devices.c  | 22 +++++++++++++++++-----
>>   drivers/resctrl/mpam_internal.h |  3 ---
>>   2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 0dd048279e02..db4cec710091 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -1039,7 +1039,6 @@ static void write_msmon_ctl_flt_vals(struct mon_read *m, u32 ctl_val,
>>   		mpam_write_monsel_reg(msc, CFG_MBWU_CTL, ctl_val | MSMON_CFG_x_CTL_EN);
>>
>>   		mbwu_state = &m->ris->mbwu_state[m->ctx->mon];
>> -		mbwu_state->prev_val = 0;
>>
>>   		break;
>>   	default:
>> @@ -1062,6 +1061,16 @@ static u64 mpam_msmon_overflow_val(enum mpam_device_features type)
>>   	}
>>   }
>>
>> +static bool read_msmon_mbwu_is_overflow(struct mpam_msc *msc)
>> +{
>> +	u32 ctl;
>> +
>> +	ctl = mpam_read_monsel_reg(msc, CFG_MBWU_CTL);
>> +	return ctl & (MSMON_CFG_x_CTL_OFLOW_STATUS |
>> +		      MSMON_CFG_MBWU_CTL_OFLOW_STATUS_L) ?
>> +		      true : false;
>> +}
>> +
>>   /* Call with MSC lock held */
>>   static void __ris_msmon_read(void *arg)
>>   {
>> @@ -1069,6 +1078,7 @@ static void __ris_msmon_read(void *arg)
>>   	bool config_mismatch;
>>   	struct mon_read *m = arg;
>>   	u64 now, overflow_val = 0;
>> +	bool mbwu_overflow = false;
>>   	struct mon_cfg *ctx = m->ctx;
>>   	bool reset_on_next_read = false;
>>   	struct mpam_msc_ris *ris = m->ris;
>> @@ -1091,6 +1101,7 @@ static void __ris_msmon_read(void *arg)
>>   			reset_on_next_read = mbwu_state->reset_on_next_read;
>>   			mbwu_state->reset_on_next_read = false;
>>   		}
>> +		mbwu_overflow = read_msmon_mbwu_is_overflow(msc);
>>   	}
>>
>>   	/*
>> @@ -1103,8 +1114,10 @@ static void __ris_msmon_read(void *arg)
>>   	config_mismatch = cur_flt != flt_val ||
>>   			  cur_ctl != (ctl_val | MSMON_CFG_x_CTL_EN);
>>
>> -	if (config_mismatch || reset_on_next_read)
>> +	if (config_mismatch || reset_on_next_read) {
>>   		write_msmon_ctl_flt_vals(m, ctl_val, flt_val);
>> +		mbwu_overflow = false;
>> +	}
>>
>>   	switch (m->type) {
>>   	case mpam_feat_msmon_csu:
>> @@ -1138,10 +1151,9 @@ static void __ris_msmon_read(void *arg)
>>   		mbwu_state = &ris->mbwu_state[ctx->mon];
>>
>>   		/* Add any pre-overflow value to the mbwu_state->val */
>> -		if (mbwu_state->prev_val > now)
>> -			overflow_val = mpam_msmon_overflow_val(m->type) - mbwu_state->prev_val;
> 
> This all looks fine for overflow, but what we've been forgetting about
> is the power management. As James mentioned in his commit message, the
> prev_val is after now check is doing double duty. If an msc is powered
> down and reset then we lose the count. Hence, to keep an accurate count,
> we should be considering this case too.
> 


Regarding CPU power management and CPU on-/off-line scenarios, this
should and already has been handled by mpam_save_mbwu_state():

1. Freezes the current MSMON_MBWU counter into the
mbwu_state->correction;
2. Clears the MSMON_MBWU counter;

After the CPU is powered back on, the total bandwidth traffic is
MSMON_MBWU(the `now` variable) + correction.

So the above solution also covers CPU power-down scenarios, and no
additional code is needed to adapt to this case.

If I've missed anything, thanks in advance to point it out.


Best Regards,
Zeng Heng