Re: [PATCH] arm64/kernel: Expose the running CPU of a native task in TPIDRRO_EL0

["Guilherme G. Piccoli" <gpiccoli@igalia.com>]

On 17/08/2026 05:51, Catalin Marinas wrote:
> On Sun, Aug 16, 2026 at 10:51:12AM +0100, Will Deacon wrote:
>> On Sat, Aug 15, 2026 at 12:19:32PM -0300, Guilherme G. Piccoli wrote:
>>> The register TPIDRRO_EL0 has 2 meanings / usages today, depending on
>>> the mode userspace is running:
>>>
>>> - For native/arm64 mode, this register is always 0 from the userspace
>>>   perspective. In the kernel, it is used during ventry (entry.S) as
>>>   a scratch register, related to KPTI (stashes x30 in fact).
>>>
>>> - For 32-bit compat tasks, this register holds the TLS userspace pointer,
>>>   and is not used for KPTI or anything else in entry.S. This is ABI and
>>>   userspace can count on having a valid TLS pointer there.
>>>
>>> Happens that other operating systems follow a similar approach than 32-bit
>>> compat mode, even for arm64: in both Windows[0] and MacOS (xnu/darwin)[1],
>>> this register is used to hold the running CPU of the current task, hence
>>> offering a very fast / non-syscall way for a given task to figure its
>>> running CPU id.
>>
>> I don't think we should allocate TPIDRRO_EL0 for this as it precludes us
>> using it for anything else in the future. If you want the current CPU,
>> then I think you're better off using either rseq (which I thought could
>> do this) or looking at reviving the vDSO work you mention (but that has
>> unresolved limitations iirc).
> 
> Indeed. IIRC glibc already implements getcpu() using rseq.
> 

Hi Will / Catalin / all,
first of all, thanks for your prompt responses!

I'm a bit confused on what "using the register" means here. We have 2
ways of using it, IIUC:

a) Use it as it's already used today! On kernel space, this register is
kinda free, right? Currently, it's used as the scratch, in the entry.
But nothing prevents other usages, given that, as the final step of exit
to EL0, it's restored to the value of the CPU id. So, AFAIU, it's fair
use on kernel space with or without this patch.

b) Use as in "expose something else to userspace". Is it OK doing that,
even the ARM specification mentioning

"Purpose
Provides a location where software executing at EL1 or higher can store
thread identifying information that is visible to software executing at
EL0, for OS management purposes." ?

Or do you mean exposing **different information** than the pure CPU id,
but still related with thread information?

Would it be better if we guard this usage with a Kconfig? Or as Ryan
already said, prctl flag or another idea?


Finally, I would like to reinforce / disambiguate things here (though
Ryan already mentioned): rseq or vDSO **are not** valid resources for
our use case. What we are really interested is in having this register
filled with CPU id.
Cheers,


Guilherme