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

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

Will