When the "mbm_event" counter assignment mode is enabled, a hardware counter
must be assigned to read the event.

Report 'Unassigned' in case the user attempts to read the event without
assigning a hardware counter.

Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v15: Updated the changelog.
     Removed the error setting in rdtgroup_mondata_show(). It is already done
     in mon_event_read() based on the discussion.
     https://lore.kernel.org/lkml/b4b14670-9cb0-4f65-abd5-39db996e8da9@intel.com/

v14: Updated the changelog.
     Added the code comment for "-ENOENT" when counter is read without assignement.
     Removed the references to resctrl_is_mbm_event().

v13: Minor commitlog and user doc update.
     Resolved conflicts caused by the recent FS/ARCH code restructure.
     The monitor.c/rdtgroup.c files have been split between the FS and ARCH directories.

v12: Updated the documentation for more clarity.

v11: Domain can be NULL with SNC support so moved the unassign check in
     rdtgroup_mondata_show().

v10: Moved the code to check the assign state inside mon_event_read().
     Fixed few text comments.

v9: Used is_mbm_event() to check the event type.
    Minor user documentation update.

v8: Used MBM_EVENT_ARRAY_INDEX to get the index for the MBM event.
    Documentation update to make the text generic.

v7: Moved the documentation under "mon_data".
    Updated the text little bit.

v6: Added more explaination in the resctrl.rst
    Added checks to detect "Unassigned" before reading RMID.

v5: New patch.
---
 Documentation/filesystems/resctrl.rst | 8 ++++++++
 fs/resctrl/ctrlmondata.c              | 6 ++++++
 2 files changed, 14 insertions(+)

diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index 446736dbd97f..4f5eb5bbd4b5 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
 	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
 	where "YY" is the node number.
 
+	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
+	counters and allows users to assign counters to mon_hw_id, event pairs
+	enabling bandwidth monitoring for as long as the counter remains assigned.
+	The hardware will continue tracking the assigned counter until the user
+	manually unassigns it, ensuring that event data is not reset during this
+	period. An MBM event returns 'Unassigned' when the event does not have
+	a hardware counter assigned.
+
 "mon_hw_id":
 	Available only with debug option. The identifier used by hardware
 	for the monitor group. On x86 this is the RMID.
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index ce766b2cdfc1..45351673e4ee 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -661,10 +661,16 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
 
 checkresult:
 
+	/*
+	 * -ENOENT is a special case, set only when "mbm_event" counter assignment
+	 * mode is enabled and no counter has been assigned.
+	 */
 	if (rr.err == -EIO)
 		seq_puts(m, "Error\n");
 	else if (rr.err == -EINVAL)
 		seq_puts(m, "Unavailable\n");
+	else if (rr.err == -ENOENT)
+		seq_puts(m, "Unassigned\n");
 	else
 		seq_printf(m, "%llu\n", rr.val);
 
-- 
2.34.1

Hi Babu,

On 7/8/25 3:17 PM, Babu Moger wrote:
> When the "mbm_event" counter assignment mode is enabled, a hardware counter
> must be assigned to read the event.
> 
> Report 'Unassigned' in case the user attempts to read the event without
> assigning a hardware counter.
> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---



> ---
>  Documentation/filesystems/resctrl.rst | 8 ++++++++
>  fs/resctrl/ctrlmondata.c              | 6 ++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index 446736dbd97f..4f5eb5bbd4b5 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
>  	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>  	where "YY" is the node number.
>  
> +	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
> +	counters and allows users to assign counters to mon_hw_id, event pairs
> +	enabling bandwidth monitoring for as long as the counter remains assigned.
> +	The hardware will continue tracking the assigned counter until the user
> +	manually unassigns it, ensuring that event data is not reset during this
> +	period. An MBM event returns 'Unassigned' when the event does not have
> +	a hardware counter assigned.

Most of this duplicates the "mbm_event" description added in patch #10. It should just
be sufficient to mention that this applies to "mbm_event" counter assignment mode
and then user can look up the main description in the doc.

The last sentence is related to this section and need an update to reflect behavior
when a CTRL_MON event is read and it or some of the MON groups do not have
counters assigned. The paragraph that precedes this does describe how the sum
works so this can tie into that.


> +
>  "mon_hw_id":
>  	Available only with debug option. The identifier used by hardware
>  	for the monitor group. On x86 this is the RMID.
> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
> index ce766b2cdfc1..45351673e4ee 100644
> --- a/fs/resctrl/ctrlmondata.c
> +++ b/fs/resctrl/ctrlmondata.c
> @@ -661,10 +661,16 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
>  
>  checkresult:
>  
> +	/*
> +	 * -ENOENT is a special case, set only when "mbm_event" counter assignment
> +	 * mode is enabled and no counter has been assigned.
> +	 */
>  	if (rr.err == -EIO)
>  		seq_puts(m, "Error\n");
>  	else if (rr.err == -EINVAL)
>  		seq_puts(m, "Unavailable\n");
> +	else if (rr.err == -ENOENT)
> +		seq_puts(m, "Unassigned\n");
>  	else
>  		seq_printf(m, "%llu\n", rr.val);
>  

As mentioned in previous patch, please squash with previous patch.

Reinette

Hi Reinette,

On 7/17/25 22:53, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/8/25 3:17 PM, Babu Moger wrote:
>> When the "mbm_event" counter assignment mode is enabled, a hardware counter
>> must be assigned to read the event.
>>
>> Report 'Unassigned' in case the user attempts to read the event without
>> assigning a hardware counter.
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
> 
> 
> 
>> ---
>>  Documentation/filesystems/resctrl.rst | 8 ++++++++
>>  fs/resctrl/ctrlmondata.c              | 6 ++++++
>>  2 files changed, 14 insertions(+)
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index 446736dbd97f..4f5eb5bbd4b5 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
>>  	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>>  	where "YY" is the node number.
>>  
>> +	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
>> +	counters and allows users to assign counters to mon_hw_id, event pairs
>> +	enabling bandwidth monitoring for as long as the counter remains assigned.
>> +	The hardware will continue tracking the assigned counter until the user
>> +	manually unassigns it, ensuring that event data is not reset during this
>> +	period. An MBM event returns 'Unassigned' when the event does not have
>> +	a hardware counter assigned.
> 
> Most of this duplicates the "mbm_event" description added in patch #10. It should just
> be sufficient to mention that this applies to "mbm_event" counter assignment mode
> and then user can look up the main description in the doc.
> 
> The last sentence is related to this section and need an update to reflect behavior
> when a CTRL_MON event is read and it or some of the MON groups do not have
> counters assigned. The paragraph that precedes this does describe how the sum
> works so this can tie into that.

Just added following text.

When the 'mbm_event' counter assignment mode is enabled, reading
an MBM event returns 'Unassigned' if no hardware counter is assigned
to it. For CTRL_MON groups, 'Unassigned' is returned if none of the
events in the CTRL_MON group or its associated MON groups have assigned
counters.


> 
>> +
>>  "mon_hw_id":
>>  	Available only with debug option. The identifier used by hardware
>>  	for the monitor group. On x86 this is the RMID.
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index ce766b2cdfc1..45351673e4ee 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -661,10 +661,16 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
>>  
>>  checkresult:
>>  
>> +	/*
>> +	 * -ENOENT is a special case, set only when "mbm_event" counter assignment
>> +	 * mode is enabled and no counter has been assigned.
>> +	 */
>>  	if (rr.err == -EIO)
>>  		seq_puts(m, "Error\n");
>>  	else if (rr.err == -EINVAL)
>>  		seq_puts(m, "Unavailable\n");
>> +	else if (rr.err == -ENOENT)
>> +		seq_puts(m, "Unassigned\n");
>>  	else
>>  		seq_printf(m, "%llu\n", rr.val);
>>  
> 
> As mentioned in previous patch, please squash with previous patch.
> 
Sure.

-- 
Thanks
Babu Moger

Hi Babu,

On 7/22/25 11:15 AM, Moger, Babu wrote:
> Hi Reinette,
> 
> On 7/17/25 22:53, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 7/8/25 3:17 PM, Babu Moger wrote:
>>> When the "mbm_event" counter assignment mode is enabled, a hardware counter
>>> must be assigned to read the event.
>>>
>>> Report 'Unassigned' in case the user attempts to read the event without
>>> assigning a hardware counter.
>>>
>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>> ---
>>
>>
>>
>>> ---
>>>  Documentation/filesystems/resctrl.rst | 8 ++++++++
>>>  fs/resctrl/ctrlmondata.c              | 6 ++++++
>>>  2 files changed, 14 insertions(+)
>>>
>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>> index 446736dbd97f..4f5eb5bbd4b5 100644
>>> --- a/Documentation/filesystems/resctrl.rst
>>> +++ b/Documentation/filesystems/resctrl.rst
>>> @@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
>>>  	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>>>  	where "YY" is the node number.
>>>  
>>> +	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
>>> +	counters and allows users to assign counters to mon_hw_id, event pairs
>>> +	enabling bandwidth monitoring for as long as the counter remains assigned.
>>> +	The hardware will continue tracking the assigned counter until the user
>>> +	manually unassigns it, ensuring that event data is not reset during this
>>> +	period. An MBM event returns 'Unassigned' when the event does not have
>>> +	a hardware counter assigned.
>>
>> Most of this duplicates the "mbm_event" description added in patch #10. It should just
>> be sufficient to mention that this applies to "mbm_event" counter assignment mode
>> and then user can look up the main description in the doc.
>>
>> The last sentence is related to this section and need an update to reflect behavior
>> when a CTRL_MON event is read and it or some of the MON groups do not have
>> counters assigned. The paragraph that precedes this does describe how the sum
>> works so this can tie into that.
> 
> Just added following text.
> 
> When the 'mbm_event' counter assignment mode is enabled, reading

Not sure how this will turn out ... if I understand correctly it follows a
paragraph that already starts with "The "mbm_event" counter assignment mode offers ..."
so there seems to be some redundancy.

> an MBM event returns 'Unassigned' if no hardware counter is assigned

How about "reading an MBM event" -> "reading an MBM of a MON group" to
distinguish it from the text about CTRL_MON group that follows it?

> to it. For CTRL_MON groups, 'Unassigned' is returned if none of the
> events in the CTRL_MON group or its associated MON groups have assigned
> counters.
> 

Reinette

Hi Reinette,

On 7/22/2025 6:28 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/22/25 11:15 AM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 7/17/25 22:53, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 7/8/25 3:17 PM, Babu Moger wrote:
>>>> When the "mbm_event" counter assignment mode is enabled, a hardware counter
>>>> must be assigned to read the event.
>>>>
>>>> Report 'Unassigned' in case the user attempts to read the event without
>>>> assigning a hardware counter.
>>>>
>>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>>> ---
>>>
>>>
>>>
>>>> ---
>>>>   Documentation/filesystems/resctrl.rst | 8 ++++++++
>>>>   fs/resctrl/ctrlmondata.c              | 6 ++++++
>>>>   2 files changed, 14 insertions(+)
>>>>
>>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>>> index 446736dbd97f..4f5eb5bbd4b5 100644
>>>> --- a/Documentation/filesystems/resctrl.rst
>>>> +++ b/Documentation/filesystems/resctrl.rst
>>>> @@ -434,6 +434,14 @@ When monitoring is enabled all MON groups will also contain:
>>>>   	for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>>>>   	where "YY" is the node number.
>>>>   
>>>> +	The "mbm_event" counter assignment mode offers "num_mbm_cntrs" number of
>>>> +	counters and allows users to assign counters to mon_hw_id, event pairs
>>>> +	enabling bandwidth monitoring for as long as the counter remains assigned.
>>>> +	The hardware will continue tracking the assigned counter until the user
>>>> +	manually unassigns it, ensuring that event data is not reset during this
>>>> +	period. An MBM event returns 'Unassigned' when the event does not have
>>>> +	a hardware counter assigned.
>>>
>>> Most of this duplicates the "mbm_event" description added in patch #10. It should just
>>> be sufficient to mention that this applies to "mbm_event" counter assignment mode
>>> and then user can look up the main description in the doc.
>>>
>>> The last sentence is related to this section and need an update to reflect behavior
>>> when a CTRL_MON event is read and it or some of the MON groups do not have
>>> counters assigned. The paragraph that precedes this does describe how the sum
>>> works so this can tie into that.
>>
>> Just added following text.
>>
>> When the 'mbm_event' counter assignment mode is enabled, reading
> 
> Not sure how this will turn out ... if I understand correctly it follows a
> paragraph that already starts with "The "mbm_event" counter assignment mode offers ..."
> so there seems to be some redundancy.

There is no redundant text now. . Users can look up about "mbm_event" 
from "mbm_assign_mode". Here is the complete diff.

diff --git a/Documentation/filesystems/resctrl.rst 
b/Documentation/filesystems/resctrl.rst
index 446736dbd97f..01c33f62ce74 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -434,6 +434,12 @@ When monitoring is enabled all MON groups will also 
contain:
         for the L3 cache they occupy). These are named "mon_sub_L3_YY"
         where "YY" is the node number.

+       When the 'mbm_event' counter assignment mode is enabled, reading
+       an MBM event of a MON group returns 'Unassigned' if no hardware
+       counter is assigned to it. For CTRL_MON groups, 'Unassigned' is
+       returned if none of the events in the CTRL_MON group or its
+       associated MON groups have assigned counters.
+
  "mon_hw_id":
         Available only with debug option. The identifier used by hardware
         for the monitor group. On x86 this is the RMID.



>> an MBM event returns 'Unassigned' if no hardware counter is assigned
> 
> How about "reading an MBM event" -> "reading an MBM of a MON group" to
> distinguish it from the text about CTRL_MON group that follows it?
> 
>> to it. For CTRL_MON groups, 'Unassigned' is returned if none of the
>> events in the CTRL_MON group or its associated MON groups have assigned
>> counters.
>>
> 
> Reinette
>

Hi Babu,

On 7/22/25 5:26 PM, Moger, Babu wrote:
> 
> There is no redundant text now. . Users can look up about "mbm_event" from "mbm_assign_mode". Here is the complete diff.
> 
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index 446736dbd97f..01c33f62ce74 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -434,6 +434,12 @@ When monitoring is enabled all MON groups will also contain:
>         for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>         where "YY" is the node number.
> 
> +       When the 'mbm_event' counter assignment mode is enabled, reading
> +       an MBM event of a MON group returns 'Unassigned' if no hardware
> +       counter is assigned to it. For CTRL_MON groups, 'Unassigned' is
> +       returned if none of the events in the CTRL_MON group or its
> +       associated MON groups have assigned counters.

The "none of the events" could be interpreted wrongly with only one MBM event
being read. How about the last sentence as:
	For CTRL_MON groups, 'Unassigned' is returned if the MBM event does not
	have an assigned counter in the CTRL_MON group nor in any of its associated
	MON groups.

Reinette

Hi Reinette,

On 7/22/2025 9:05 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/22/25 5:26 PM, Moger, Babu wrote:
>>
>> There is no redundant text now. . Users can look up about "mbm_event" from "mbm_assign_mode". Here is the complete diff.
>>
>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>> index 446736dbd97f..01c33f62ce74 100644
>> --- a/Documentation/filesystems/resctrl.rst
>> +++ b/Documentation/filesystems/resctrl.rst
>> @@ -434,6 +434,12 @@ When monitoring is enabled all MON groups will also contain:
>>          for the L3 cache they occupy). These are named "mon_sub_L3_YY"
>>          where "YY" is the node number.
>>
>> +       When the 'mbm_event' counter assignment mode is enabled, reading
>> +       an MBM event of a MON group returns 'Unassigned' if no hardware
>> +       counter is assigned to it. For CTRL_MON groups, 'Unassigned' is
>> +       returned if none of the events in the CTRL_MON group or its
>> +       associated MON groups have assigned counters.
> 
> The "none of the events" could be interpreted wrongly with only one MBM event
> being read. How about the last sentence as:
> 	For CTRL_MON groups, 'Unassigned' is returned if the MBM event does not
> 	have an assigned counter in the CTRL_MON group nor in any of its associated
> 	MON groups.
> 

Yes. Looks good.
Thanks
Babu