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:
> > 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