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

Message-ID: <efa92bef-8bfb-431f-ac9e-048041ff13f6@arm.com>
Date: Fri, 27 Jun 2025 17:38:48 +0100
From: James Morse <james.morse@....com>
To: Rob Herring <robh@...nel.org>
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

Hi Rob,

On 23/06/2025 16:05, Rob Herring wrote:
> 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.

Some hardware specific value, that would have to come from the DT...

> It's never going to be the cache id directly since that is per level.

Can re-used across levels, but because they can also be sparse its equally valid for them
to be unique. This is what is happening on arm64 ACPI platforms.

> 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.

ACPI currently requires some kernel interaction too as the value gets written to some
platform specific register. Even if it did get standardised, I guess something like VFIO
would manage access to that register to fix up the values.

Thanks,

James