Re: [PATCH v4 3/6] x86/resctrl: Rename prev_msr to prev_mon_val

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Chenyu,

On 6/22/26 5:42 AM, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 6/19/2026 7:39 AM, Reinette Chatre wrote:
>> Hi Chenyu,
>>
>> On 6/13/26 12:57 AM, Chen Yu wrote:
>>> Rename the prev_msr field in struct arch_mbm_state to prev_mon_val.
>>
>> This change as described seems out of place when considering the following
>> from cover letter:
>>   This patch set focuses on the first part: enabling MMIO-based access for
>>   Cache Monitoring Technology (CMT), *while CAT/MBM/MBA are still using MSR*.
>>
>> It is thus confusing to find a change related to switching MBM to use MSR
>> in a series that claims that it does not do this.
>>
>> The patch looks fine but reading the changelog and the first few hunks makes
>> this patch look out of place. Could you please update the changelog to be
>> accurate about what this patch does?
>>
> 
> OK, let me change it to:
> 
> x86/resctrl: Rename prev_msr to prev_mon_val
> 
> Rename the prev_msr field in struct arch_mbm_state to prev_mon_val
> to decouple the field name from the specific access method.

This patch changes many more names to support this switch to MMIO yet the changelog
only highlights one of the changes which is the struct member specific to MBM while
the work explicitly states that MBM monitoring is not impacted by this series.

Consider for comparison a more generic (just a draft to present an idea, please do not just copy&paste):
	x86/resctrl: Replace "msr" in monitoring data identifiers

	Monitoring data is only consumed via MSR and many identifiers handling
	the monitoring data contains "msr" as part of their names, for example
	"msr_val". 

	Replace "msr" in monitoring data identifiers as appropriate to support
	their use for monitoring data accessed via MMIO.

> 
> Use a generic name for the stored previous monitoring counter value
> so that the field remains accurate regardless of whether the value
> is read through an MSR or another interface in the future.
> 
> No functional change.
> 
> thanks,
> Chenyu