linux-kernel - Re: [RFC PATCH v3 00/17] 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: <ZikULOsS+AtXaeQG@e133380.arm.com>
Date: Wed, 24 Apr 2024 15:16:12 +0100
From: Dave Martin <Dave.Martin@....com>
To: Reinette Chatre <reinette.chatre@...el.com>
Cc: "Moger, Babu" <babu.moger@....com>,
	Peter Newman <peternewman@...gle.com>, corbet@....net,
	fenghua.yu@...el.com, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, 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, maciej.wieczor-retman@...el.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	eranian@...gle.com, james.morse@....com
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)

On Tue, Apr 23, 2024 at 09:15:07PM -0700, Reinette Chatre wrote:
> 
> 
> On 4/23/2024 5:37 AM, Dave Martin wrote:
> > On Mon, Apr 22, 2024 at 03:44:26PM -0500, Moger, Babu wrote:
> >> Hi Dave,
> >>
> >> On 4/22/24 11:34, Dave Martin wrote:
> >>> Hi Babu,
> >>>
> >>> On Thu, Apr 04, 2024 at 03:02:45PM -0500, Moger, Babu wrote:
> >>>> Hi Peter,
> >>>>
> >>>>
> >>>> On 4/4/24 14:08, Peter Newman wrote:
> >>>>> Hi Babu,
> >>>>>
> >>>>> On Thu, Mar 28, 2024 at 6:07 PM Babu Moger <babu.moger@....com> wrote:
> >>>>>>    The list follows the following format:
> >>>>>>
> >>>>>>        * Default CTRL_MON group:
> >>>>>>                "//<domain_id>=<assignment_flags>"
> >>>>>>
> >>>>>>        * Non-default CTRL_MON group:
> >>>>>>                "<CTRL_MON group>//<domain_id>=<assignment_flags>"
> >>>>>>
> >>>>>>        * Child MON group of default CTRL_MON group:
> >>>>>>                "/<MON group>/<domain_id>=<assignment_flags>"
> >>>>>>
> >>>>>>        * Child MON group of non-default CTRL_MON group:
> >>>>>>                "<CTRL_MON group>/<MON group>/<domain_id>=<assignment_flags>"
> >>>>>>
> >>>>>>        Assignment flags can be one of the following:
> >>>>>>
> >>>>>>         t  MBM total event is assigned
> >>>>>>         l  MBM local event is assigned
> >>>>>>         tl Both total and local MBM events are assigned
> >>>>>>         _  None of the MBM events are assigned
> >>>>>>
> >>>>>>         Examples:
> >>>>>>
> >>>>>>         # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
> >>>>>>         non_defult_group//0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
> >>>>>>         non_defult_group/non_default_mon1/0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
> >>>>>>         //0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
> >>>>>>         /default_mon1/0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
> >>>>>>
> >>>>>>         There are four groups and all the groups have local and total event assigned.
> >>>>>>
> >>>>>>         "//" - This is a default CONTROL MON group
> >>>>>>
> >>>>>>         "non_defult_group//" - This is non default CONTROL MON group
> >>>>>>
> >>>>>>         "/default_mon1/"  - This is Child MON group of the defult group
> >>>>>>
> >>>>>>         "non_defult_group/non_default_mon1/" - This is child MON group of the non default group
> >>>>>>
> >>>>>>         =tl means both total and local events are assigned.
> >>>>>
> >>>>> I recall there was supposed to be a way to perform the same update on
> >>>>> all domains together so that it isn't tedious to not do per-domain
> >>>>
> >>>> Yes. Correct. Reinette suggested to have "no domains" means ALL the domains.
> >>>
> >>> Would "*" be more intuitive?
> >>
> >> We could. But I don't see the need for wildcard ("*") or ranges and
> >> complexity that comes with that.
> > 
> > For "*", I mean that this would just stand for "all cpus", not a generic
> > string match; apologies if I didn't make that clear.
> 
> (reading this by replacing "all cpus" with "all domains")
> 
> This sounds reasonable to me. It may indeed make the parsing simpler by
> not needing the ugly checks Babu mentioned in [1].
> 
> Reinette
> 
> [1] https://lore.kernel.org/lkml/7ccd59b8-9fe3-4d1f-82f5-f33d96dbf5ac@amd.com/

Ack, I meant "all domains", sorry!

Note, should we try to detect things like:

	<resource>:0=fee;1=fie;*=foe;0=fum

.?

Either we treat conflicting assignments as an error, or we do them all
in the order specified, so that assignments on the right override those
on the left (which is what the schemata parsing in ctrlmondata.c:
parse_line() seems to do today if I understand the code correctly).

In the latter case,

	<resource>:*=fee;1=fie

would set all nodes except 1 to "fee", and node 1 to "fie", which might
be useful (or at least, convenient).

If we're worried about that being exposed as ABI and used by userspace,
we might want to disallow it explicitly.

Cheers
---Dave