linux-kernel - Re: [PATCH 0/5] cacheinfo: Set cache 'id' based on DT data

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] [day] [month] [year] [list]

Message-ID: <CAL_JsqKD7yOxSnfnah2gE0EodtQ4KyJ2_qXmMu2oK9i6numzwA@mail.gmail.com>
Date: Mon, 23 Jun 2025 10:05:35 -0500
From: Rob Herring <robh@...nel.org>
To: James Morse <james.morse@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J . Wysocki" <rafael@...nel.org>, sudeep.holla@....com, 
	Ben Horgan <ben.horgan@....com>
Subject: Re: [PATCH 0/5] cacheinfo: Set cache 'id' based on DT data

On Fri, Jun 13, 2025 at 8:04 AM James Morse <james.morse@....com> wrote:
>
> This series adds support for cache-ids to device-tree systems.
> These values are exposed to user-space via
> /sys/devices/system/cpu/cpuX/cache/indexY/id
> and are used to identify caches and their associated CPUs by kernel interfaces
> such as resctrl.
>
> Resctrl anticipates cache-ids are unique for a given cache level, but may
> be sparse. See Documentation/filesystems/resctrl.rst's "Cache IDs" section.
>
> Another user is PCIe's cache-steering hints, where an id provided by the
> hardware would be needed. Today this expects a platform specific ACPI hook
> the program that value into the PCIe root port registers. If DT platforms
> are ever supported, it will likely need a kernel driver to convert the
> user-space cache-id to whatever hardware value is needed.
>
> Rob H previously preferred to generate a cache-id from the information DT
> already has. (Rob: does the PCIe cache-steering use-case change this?)

I don't think so because who knows what values the PCI root port
needs. It's never going to be the cache id directly since that is per
level. So we'd need some sort of mapping. That's going to be something
like this:

Userspace level+id -> DT cache node -> PCI RP value

So the first translation is the same as you have here. The 2nd
translation might be something we put in DT or could be in PCI host
bridge driver.

Rob