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: <799f514f-b06e-46d9-bfe7-dfd986aef166@intel.com>
Date: Mon, 14 Oct 2024 13:05:56 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>, "babu.moger@....com"
	<babu.moger@....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 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.

> 
> Current implementation would show same number for all domains.
> 

Reinette

[1] https://lore.kernel.org/all/c8a23c54-237c-4ebb-9c88-39606b9ae1ab@intel.com/