linux-kernel - RE: [PATCH v4 0/8] Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)

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: <SJ1PR11MB6083919B4628C4957D099667FC8E2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Mon, 5 May 2025 17:01:49 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Chatre, Reinette" <reinette.chatre@...el.com>, "Moger, Babu"
	<bmoger@....com>, Babu Moger <babu.moger@....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>
CC: "corbet@....net" <corbet@....net>, "x86@...nel.org" <x86@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "paulmck@...nel.org" <paulmck@...nel.org>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "thuth@...hat.com"
	<thuth@...hat.com>, "ardb@...nel.org" <ardb@...nel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>,
	"mario.limonciello@....com" <mario.limonciello@....com>, "perry.yuan@....com"
	<perry.yuan@....com>, "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
	<kai.huang@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>, "riel@...riel.com"
	<riel@...riel.com>, "Li, Xin3" <xin3.li@...el.com>, "xin@...or.com"
	<xin@...or.com>, "Mehta, Sohil" <sohil.mehta@...el.com>, "ak@...ux.intel.com"
	<ak@...ux.intel.com>, "ebiggers@...gle.com" <ebiggers@...gle.com>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"gautham.shenoy@....com" <gautham.shenoy@....com>, "Xiaojian.Du@....com"
	<Xiaojian.Du@....com>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "james.morse@....com" <james.morse@....com>,
	"fenghuay@...dia.com" <fenghuay@...dia.com>, "peternewman@...gle.com"
	<peternewman@...gle.com>
Subject: RE: [PATCH v4 0/8] Support L3 Smart Data Cache Injection Allocation
 Enforcement (SDCIAE)

> The only aspect of "closids" that has been exposed to user space thus far
> is the "num_closids" and in user documentation a CLOSid has been linked to the
> number of control groups. That is the only constraint we need to think about
> here. I have repeatedly asked for IO alloc connection with CLOSIDs to not be exposed
> to user space (yet user documentation and messages to user space keeps doing so
> in this series). Support for IO alloc in this way is unique to AMD. We do not want
> resctrl to be constrained like this if another architecture needs to support
> some form of IO alloc and does so in a different way.

This isn't unique to AMD. Intel also ties CLOSid to control features associated with
I/O (likewise with RMIDs for monitoring).

See the Intel RDT architecture specification[1] chapter 4.4:

" Non-CPU agent RDT uses the RMID and CLOS tags in the same way that they are used for CPU agents."

-Tony

[1] https://cdrdv2.intel.com/v1/dl/getContent/789566