linux-kernel - Re: [PATCH v11 10/23] x86/resctrl: Remove MSR reading of event configuration value

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: <d0b12fb3-3deb-4327-86e4-519b495c0cac@arm.com>
Date: Fri, 21 Feb 2025 18:08:10 +0000
From: James Morse <james.morse@....com>
To: "Luck, Tony" <tony.luck@...el.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>,
 Babu Moger <babu.moger@....com>, "corbet@....net" <corbet@....net>,
 "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>,
 "peternewman@...gle.com" <peternewman@...gle.com>
Cc: "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
 "paulmck@...nel.org" <paulmck@...nel.org>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "thuth@...hat.com" <thuth@...hat.com>,
 "rostedt@...dmis.org" <rostedt@...dmis.org>,
 "xiongwei.song@...driver.com" <xiongwei.song@...driver.com>,
 "pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
 "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
 "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
 "perry.yuan@....com" <perry.yuan@....com>,
 "sandipan.das@....com" <sandipan.das@....com>,
 "Huang, Kai" <kai.huang@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>, "Li, Xin3" <xin3.li@...el.com>,
 "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
 "ebiggers@...gle.com" <ebiggers@...gle.com>,
 "mario.limonciello@....com" <mario.limonciello@....com>,
 "tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>,
 "Eranian, Stephane" <eranian@...gle.com>
Subject: Re: [PATCH v11 10/23] x86/resctrl: Remove MSR reading of event
 configuration value

Hi Tony, Reinette,

On 2/6/25 15:56, Luck, Tony wrote:
>>>> This new arch API has sharp corners because of asymmetry of where resctrl
>>>> runs the arch function. I do not think it is required to change this since we
>>>> can only speculate about how this may be used in the future but I do think
>>>> it will be helpful to add comments that highlight:
>>>>
>>>> resctrl_arch_mon_event_config_get() ->  May run on CPU that does not belong to domain.
>>>> resctrl_arch_mon_event_config_set() ->  Runs on CPU that belongs to domain.
>>>
>>> Here's a vague data point about the future to help with speculation.
>>>
>>> I have something coming along the pipeline that also can run on any CPU.

RISC-V has this - all their controls/monitors are accessible from any CPU.
Some MPAM platforms can do this too - but the code has to be structured for those
that need the IPI.

Having this be something resctrl can be told sounds like a great idea.

It sounds like all or nothing suits x86/riscv.
The MPAM driver has an accessibility cpumask for each thing it accesses that determines
if it needs to do an IPI.


>>> I am contemplating a flag in the rdt_resource structure (in appropriate substructure
>>> resctrl_cache/resctrl_membw) to indicate "domain" vs. "any" for operations.
>>>
>>> Would something like that be useful here?
>>
>> hmm ... I cannot envision how this may look. Could you please elaborate?
>>
>> You mention "a" (singular) flag in rdt_resource while this scenario involves
>> different ops having different scope. This makes me think that this flag may
>> have to be per operation that in turn would need additional infrastructure to
>> manage and track operations.
>>
>> These "arch" functions are evolving as the work to support MPAM is done and
>> so far I think it has been quite ad-hoc to just refactor arch specific code
>> into "arch" helpers instead of keeping track of which scope they are running in.
>> This currently requires any arch implementing an "arch" helper to be well aware
>> of how resctrl will call it.

This is how APIs in linux evolve - only the immediate problem needs solving.
Arch code being aware how resctrl uses a function shouldn't be surprising - it is the only user.


> I haven't fleshed it out yet. One option would be to have a "choose_cpu_mask()"
> function that takes resource and domain parameters (and given your comment
> about this case an operation code). Then use that as the mask in an smp_call*().
> 
> Operations that can run anywhere would return a mask with just bit for the
> current CPU.

That sounds like extra work. We already have a cpumask, if you set it to the cpu_possible mask
at boot, then smp_call_function() and friends will always prefer the current CPU, and it all falls
out in the wash.


Thanks,

James