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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <223e2e24-ca77-48e4-bc5a-ce50cda9e222@arm.com>
Date: Fri, 21 Feb 2025 18:08:33 +0000
From: James Morse <james.morse@....com>
To: Dave Martin <Dave.Martin@....com>,
 Reinette Chatre <reinette.chatre@...el.com>
Cc: "Luck, Tony" <tony.luck@...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>,
 "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 Dave,

On 2/19/25 13:28, Dave Martin wrote:
> On Wed, Feb 05, 2025 at 05:41:53PM -0800, Reinette Chatre wrote:
>> On 2/5/25 4:51 PM, 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.
>>>
>>> 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.

> For MPAM, we must typically do all configuration access from a CPU in a
> power domain that depends on the power domain of the relevant MPAM MSC,
> including reads of the configuration.
This is the worst case - but the firmware can describe an MSC as being globally accessible.


> In the MPAM case, the required topology knowledge is not necessarily
> identical to the resctrl domain topology, so it doesn't feel right to
> have the resctrl core code making the decisions.

This is up to the MPAM driver to hide. The upshot is that for some calls
resctrl needs to schedule work so that the MPAM driver can in turn IPI to get
the rest of the work done. The changes for this are already upstream.


> So, in the interest of keeping the arch interface simple, should cross-
> calling be delegated to the arch code, at least for now?


That's invasive on top of what we already have. Take smp_mon_event_count() as an
example, there is a bunch of work that resctrl can do on a CPU that can access
the hardware registers. If the cpumask was hidden, then we'd either need more IPI,
or to allocate a structure that can describe a long list of monitors to read.



Thanks,

James