linux-kernel - Re: [PATCH] arm64: cacheinfo: Report cache sets, ways, and line size

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: <CAL_Jsq+TUife95L3hgafAujsHF9O81+YYV1gwq17AR_e63x0vg@mail.gmail.com>
Date: Wed, 14 May 2025 09:50:53 -0500
From: Rob Herring <robh@...nel.org>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: Mark Rutland <mark.rutland@....com>, Sudeep Holla <sudeep.holla@....com>, 
	Catalin Marinas <catalin.marinas@....com>, linux-arm-kernel@...ts.infradead.org, 
	Radu Rendec <rrendec@...hat.com>, Will Deacon <will@...nel.org>, 
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: cacheinfo: Report cache sets, ways, and line size

On Mon, May 12, 2025 at 11:27 AM Sean Anderson <sean.anderson@...ux.dev> wrote:
>
> On 5/12/25 11:36, Mark Rutland wrote:
> > On Mon, May 12, 2025 at 11:28:36AM -0400, Sean Anderson wrote:
> >> On 5/10/25 03:04, Sudeep Holla wrote:
> >> > On Fri, May 09, 2025 at 07:37:35PM -0400, Sean Anderson wrote:
> >> >> Cache geometry is exposed through the Cache Size ID register. There is
> >> >> one register for each cache, and they are selected through the Cache
> >> >> Size Selection register. If FEAT_CCIDX is implemented, the layout of
> >> >> CCSIDR changes to allow a larger number of sets and ways.
> >> >>
> >> >
> >> > Please refer
> >> > Commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing")
> >> >
> >>
> >> | The CCSIDR_EL1.{NumSets,Associativity,LineSize} fields are only for use
> >> | in conjunction with set/way cache maintenance and are not guaranteed to
> >> | represent the actual microarchitectural features of a design.
> >> |
> >> | The architecture explicitly states:
> >> |
> >> | | You cannot make any inference about the actual sizes of caches based
> >> | | on these parameters.
> >>
> >> However, on many cores (A53, A72, and surely others that I haven't
> >> checked) these *do* expose the actual microarchitectural features of the
> >> design. Maybe a whitelist would be suitable.
> >
> > Then we have to maintain a whitelist forever,
>
> There's no maintenance involved. The silicon is already fabbed, so it's
> not like it's going to change any time soon.
>
> > and running an old/distro
> > kernel on new HW won't give you useful values unless you provide
> > equivalent values in DT, in which case the kernel doesn't need to read
> > the registers anyway.
>
> Conversely (and far more likely IMO), running an old/distro devicetree
> on a new kernel won't give you usefult values. Bootloaders tend not be
> be updated very often (if ever), whereas kernels can (ideally) be
> updated without changing userspace.
>
> > The architecture explcitly tells us not to use the values in this way,
> > and it's possible to place the values into DT when you know they're
> > meaningful.
>
> Well, maybe we can just use these registers for the hundreds of existing
> devicetrees that lack values.

If the lack of values is a problem, add a schema to require them. Just
adding them as required globally isn't going to work, but nothing
prevents someone from having additional schemas for platforms they
care about or we could figure out a way to opt-in to specific schemas.

Rob