linux-kernel - Re: [PATCH v13 00/27] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f4178258-f7ad-4db2-9284-3f28e8ee8d00@intel.com>
Date: Tue, 20 May 2025 11:23:31 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: <babu.moger@....com>, Peter Newman <peternewman@...gle.com>
CC: <corbet@....net>, <tony.luck@...el.com>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
	<james.morse@....com>, <dave.martin@....com>, <fenghuay@...dia.com>,
	<x86@...nel.org>, <hpa@...or.com>, <paulmck@...nel.org>,
	<akpm@...ux-foundation.org>, <thuth@...hat.com>, <rostedt@...dmis.org>,
	<ardb@...nel.org>, <gregkh@...uxfoundation.org>,
	<daniel.sneddon@...ux.intel.com>, <jpoimboe@...nel.org>,
	<alexandre.chartre@...cle.com>, <pawan.kumar.gupta@...ux.intel.com>,
	<thomas.lendacky@....com>, <perry.yuan@....com>, <seanjc@...gle.com>,
	<kai.huang@...el.com>, <xiaoyao.li@...el.com>, <kan.liang@...ux.intel.com>,
	<xin3.li@...el.com>, <ebiggers@...gle.com>, <xin@...or.com>,
	<sohil.mehta@...el.com>, <andrew.cooper3@...rix.com>,
	<mario.limonciello@....com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <maciej.wieczor-retman@...el.com>,
	<eranian@...gle.com>, <Xiaojian.Du@....com>, <gautham.shenoy@....com>
Subject: Re: [PATCH v13 00/27] x86/resctrl : Support AMD Assignable Bandwidth
 Monitoring Counters (ABMC)

Hi Babu,

On 5/20/25 10:51 AM, Moger, Babu wrote:
> Hi Reinette,
> 
> On 5/20/25 11:06, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 5/20/25 8:28 AM, Moger, Babu wrote:
>>> On 5/19/25 10:59, Peter Newman wrote:
>>>> On Fri, May 16, 2025 at 12:52 AM Babu Moger <babu.moger@....com> wrote:
>>
>> ...
>>
>>>>> /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs: Reports the number of monitoring
>>>>> counters available for assignment.
>>>>
>>>> Earlier I discussed with Reinette[1] what num_mbm_cntrs should
>>>> represent in a "soft-ABMC" implementation where assignment is
>>>> implemented by assigning an RMID, which would result in all events
>>>> being assigned at once.
>>>>
>>>> My main concern is how many "counters" you can assign by assigning
>>>> RMIDs. I recall Reinette proposed reporting the number of groups which
>>>> can be assigned separately from counters which can be assigned.
>>>
>>> More context may be needed here. Currently, num_mbm_cntrs indicates the
>>> number of counters available per domain, which is 32.
>>>
>>> At the moment, we can assign 2 counters to each group, meaning each RMID
>>> can be associated with 2 hardware counters. In theory, it's possible to
>>> assign all 32 hardware counters to a group—allowing one RMID to be linked
>>> with up to 32 counters. However, we currently lack the interface to
>>> support that level of assignment.
>>>
>>> For now, the plan is to support basic assignment and expand functionality
>>> later once we have the necessary data structure and requirements.
>>
>> Looks like some requirements did not make it into this implementation.
>> Do you recall the discussion that resulted in you writing [2]? Looks like
>> there is a question to Peter in there on how to determine how many "counters"
>> are available in soft-ABMC. I interpreted [3] at that time to mean that this
>> information would be available in a future AMD publication.
> 
> We already have a method to determine the number of counters in soft-ABMC
> mode, which Peter has addressed [4].
> 
> [4]
> https://lore.kernel.org/lkml/20250203132642.2746754-1-peternewman@google.com/
> 
> This appears to be more of a workaround, and I doubt it will be included
> in any official AMD documentation. Additionally, the long-term direction
> is moving towards ABMC.
> 
> I don’t believe this workaround needs to be part of the current series. It
> can be added later when soft-ABMC is implemented.

Agreed. What about the plans described in [2]? (Thanks to Peter for
catching this!).

It is important to keep track of requirements while working on a feature to
ensure that the implementation supports the planned use cases. Re-reading that
thread it is not clear to me how soft-ABMC's per-group assignment would look.
Could you please share how you see it progress from this implementation?
This includes the single event vs. multiple event assignment. I would like to
highlight that this is not a request for this to be supported in this implementation
but there needs to be a plan for how this can be supported on top of interfaces
established by this work.

Reinette

> 
>>
>> Reinette
>>
>> [2] https://lore.kernel.org/lkml/afb99efe-0de2-f7ad-d0b8-f2a0ea998efd@amd.com/ 
>> [3] https://lore.kernel.org/lkml/CALPaoCg3KpF94g2MEmfP_Ro2mQZYFA8sKVkmb+7isotKNgdY9A@mail.gmail.com/
>