[PATCH] arm64: Expose CPUECTLR{,2}_EL1 via sysfs
Palmer Dabbelt
palmer at dabbelt.com
Thu Aug 7 11:14:32 PDT 2025
On Thu, 07 Aug 2025 10:57:26 PDT (-0700), broonie at kernel.org wrote:
> On Thu, Aug 07, 2025 at 10:26:29AM -0700, Palmer Dabbelt wrote:
>> On Thu, 07 Aug 2025 01:08:26 PDT (-0700), Marc Zyngier wrote:
>
>> > For a start, these encodings fall into the IMPDEF range. They won't
>> > exist on non-ARM implementations.
>
>> OK, and that's because it says "Provides additional IMPLEMENTATION DEFINED
>> configuration and control options for the processor." at the start of the
>> manual page? Sorry, I'm kind of new to trying to read the Arm specs -- I
>> thought just the meaning of the values was changing, but I probably just
>> didn't read enough specs.
>
> Yes, pretty much and also because this is in a range of registers
> reserved for use by the specific implementation. See DDI0487 (the ARM)
> version L.a sections D23.3.2 and D24.2.162 which specify the
> IMPLEMENTATION DEFINED system register range, and the definition of the
> term IMPLEMENTATION DEFINED in the glossary of DDI0487. If you see a
> small upper case term like that in a spec related to the architecture
> then it'll have a specific architectural defintion.
Thanks!
>> That said, part of the reason I just sent this as-is is because I was sort
>> of expecting the answer to be "no" here. No big deal if that's the case, we
>> can figure out some other way to solve the problem. Happy to throw some
>> time in to making some more generic flavor of this, though...
>
> It's something that does come up, working out a way to make use of the
> tuning in the IMPDEF registers in a way that generic software can safely
> and sensibly make use of is rather non-trivial though.
Ya, I'd expect it to be a bit of a time sink -- even if something like
this patch had gone in we would have had a pile of ugliness in
userspace. I think there's no way around some amount of ugliness when
it comes to implemnetation-specific, though.
That said, if our nubers do pan out here then we'll likely need to do
something. So if a more generic solution is interesting to people then
I'm happy to throw some time at it, shouldn't be too hard to justify on
my end.
More information about the linux-arm-kernel
mailing list