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

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:

quoted

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.

-- 
Catalin