linux-kernel - Re: [PATCH v7 19/24] x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <eae45121-e0bf-4076-a189-948531b89374@intel.com>
Date: Thu, 26 Sep 2024 18:50:22 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: <babu.moger@....com>, <corbet@....net>, <fenghua.yu@...el.com>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>
CC: <x86@...nel.org>, <hpa@...or.com>, <paulmck@...nel.org>,
	<rdunlap@...radead.org>, <tj@...nel.org>, <peterz@...radead.org>,
	<yanjiewtw@...il.com>, <kim.phillips@....com>, <lukas.bulwahn@...il.com>,
	<seanjc@...gle.com>, <jmattson@...gle.com>, <leitao@...ian.org>,
	<jpoimboe@...nel.org>, <rick.p.edgecombe@...el.com>,
	<kirill.shutemov@...ux.intel.com>, <jithu.joseph@...el.com>,
	<kai.huang@...el.com>, <kan.liang@...ux.intel.com>,
	<daniel.sneddon@...ux.intel.com>, <pbonzini@...hat.com>,
	<sandipan.das@....com>, <ilpo.jarvinen@...ux.intel.com>,
	<peternewman@...gle.com>, <maciej.wieczor-retman@...el.com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<eranian@...gle.com>, <james.morse@....com>
Subject: Re: [PATCH v7 19/24] x86/resctrl: Report "Unassigned" for MBM events
 in mbm_cntr_assign mode

Hi Babu,

On 9/26/24 12:16 PM, Moger, Babu wrote:
> On 9/19/24 12:31, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 9/4/24 3:21 PM, Babu Moger wrote:
>>> In mbm_cntr_assign mode, the hardware counter should be assigned to read
>>> the MBM events.
>>>
>>> Report "Unassigned" in case the user attempts to read the events without
>>> assigning the counter.
>>>
>>> Signed-off-by: Babu Moger <babu.moger@....com>
>>> ---
>>> 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/arch/x86/resctrl.rst        | 10 ++++++++++
>>>  arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 13 ++++++++++++-
>>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst
>>> index 3e9302971faf..ff5397d19704 100644
>>> --- a/Documentation/arch/x86/resctrl.rst
>>> +++ b/Documentation/arch/x86/resctrl.rst
>>> @@ -417,6 +417,16 @@ 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_cntr_assign mode allows users to assign a hardware counter
>>> +	to an RMID-event pair, enabling bandwidth monitoring for as long
>>> +	as the counter remains assigned. The hardware will continue tracking
>>> +	the assigned RMID until the user manually unassigns it, ensuring
>>> +	that counters are not reset during this period. With a limited number
>>> +	of counters, the system may run out of assignable resources. In
>>> +	mbm_cntr_assign mode, MBM event counters will return "Unassigned"
>>> +	if the counter is not allocated to the event when read. Users must
>>> +	manually assign a counter to read the events.
>>> +
>>
>> Please consider how this text could also be relevant to soft-ABMC.
> 
> It mostly applies to soft-ABMC also. Minor tweaking may be required.

hmmm ... seems that I still have mostly the "soft-RMID" model in my head.

> How about?
> 
> "When supported the 'mbm_cntr_assign' mode allows users to assign a
> hardware counter to RMID, event pair, enabling bandwidth monitoring for as

hmmm ... so soft-ABMC also assigns hardware counters?

Also, we should aim for generic text that will cover how this may look on MPAM
also. Considering this, it may just mean to replace "RMID, event pair" with 
"mon_hw_id, event pair"?

> long as the counter remains assigned. The hardware will continue tracking
> the assigned RMID until the user manually unassigns it, ensuring

Please do double-check all usage of "RMID" in user facing interfaces/docs where
mon_hw_id may be more appropriate.

> that counters are not reset during this period. With a limited number
> of counters, the system may run out of assignable counters at some point.
> In that case, MBM event counters will return "Unassigned" when the event
> when read. Users must manually assign a counter to read the events."

"when the event when read" -> "when the event is read"?

Reinette