linux-kernel - Re: [PATCH v8 08/25] x86/resctrl: Introduce interface to display number of monitoring counters

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: <3b7ca34a-764d-458e-b28c-113dc5419a4e@amd.com>
Date: Thu, 24 Oct 2024 12:29:13 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>,
 "Luck, Tony" <tony.luck@...el.com>
Cc: "corbet@....net" <corbet@....net>, "Yu, Fenghua" <fenghua.yu@...el.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
 "paulmck@...nel.org" <paulmck@...nel.org>,
 "rdunlap@...radead.org" <rdunlap@...radead.org>,
 "tj@...nel.org" <tj@...nel.org>, "peterz@...radead.org"
 <peterz@...radead.org>, "yanjiewtw@...il.com" <yanjiewtw@...il.com>,
 "kim.phillips@....com" <kim.phillips@....com>,
 "lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>,
 "jmattson@...gle.com" <jmattson@...gle.com>,
 "leitao@...ian.org" <leitao@...ian.org>,
 "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
 "Joseph, Jithu" <jithu.joseph@...el.com>, "Huang, Kai"
 <kai.huang@...el.com>, "kan.liang@...ux.intel.com"
 <kan.liang@...ux.intel.com>,
 "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "sandipan.das@....com" <sandipan.das@....com>,
 "ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
 "peternewman@...gle.com" <peternewman@...gle.com>,
 "Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Eranian, Stephane" <eranian@...gle.com>,
 "james.morse@....com" <james.morse@....com>
Subject: Re: [PATCH v8 08/25] x86/resctrl: Introduce interface to display
 number of monitoring counters

Hi Reinette/Tony,

On 10/14/24 15:05,  wrote:
> Hi Tony,
> 
> On 10/14/24 12:51 PM, Luck, Tony wrote:
>>>> What advantage does it have over skipping the per-domain list and
>>>> just providing a single value for all domains? You clearly expect this
>>>> will be a common user request since you implemented the "*" means
>>>> apply to all domains.
>>>>
>>>
>>> We started with a global assignment by applying assignment across all the
>>> domains initially.
>>>
>>> But we wanted give a generic approach which allows both the options(domain
>>> specific assignment and global assignment with '*"). It is also matches
>>> with other managements (RMID/CLOSID management) we are doing in resctrl
>>> right now. Also, there is an extra IPI for each domain if user is only
>>> interested in on domain.
>>>
>>> Some of the discussions are here.
>>> https://lore.kernel.org/lkml/f7dac996d87b4144e4c786178a7fd3d218eaebe8.1711674410.git.babu.moger@amd.com/#r
>>
>> My summary of that:
>>
>> Peter: Complex, don't need per-domain.
>> Reinette: Maybe some architecture might want per-domain.
> 
> To be specific ... we already have an architecture that supports per-domain:
> AMD's ABMC. When I considered the lifetime of user interfaces (forever?) while knowing
> that ABMC does indeed support per-domain counter assignment it seems a good
> precaution for the user interface to support that, even if the first
> implementation does not.
> 
> There are two parts to this work: (a) the new user interface
> and (b) support for ABMC. I believe that the user interface has to be
> flexible to support all ABMC features that users may want to take advantage of,
> even if the first implementation does not enable those features. In addition,
> the user interface should support future usages that we know if, "soft-ABMC"
> and MPAM.
> 
> I do not think that we should require all implementations to support everything
> made possible by user interface though. As I mentioned in that thread [1] I do
> think that the user _interface_ needs to be flexible by supporting domain level
> counter assignment, but that it may be possible that the _implementation_ only
> supports assignment to '*' domain values. 
> 
> I thus do not think we should simplify the syntax of mbm_assign_control,
> but I also do not think we should require that all implementations support all that
> the syntax makes possible. 
>  
>> Since you seem to want to keep the flexibility for a possible future
>> where per-domain is needed. The "available_mbm_cntrs" file
>> suggested in another thread would need to list available counters
>> on each domain to avoid ABI problems should that future arrive.
>>
>> $ cat num_mbm_counters
>> 32
>>
>> $ cat available_mbm_cntrs
>> 0=12;1=9
> 
> Good point.
> 

Working on this now. Wanted to confirm if we really need domain specific
information?

To me, it does not seem necessary for the user. User cannot make any
decisions based on this information.

All user wants to know is if there are global counters available.

$ cat num_mbm_counters
32

$ cat available_mbm_cntrs
15

-- 
Thanks
Babu Moger