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

[Ryan Houdek]

On Mon, Aug 17, 2026 at 1:51 AM Catalin Marinas <catalin.marinas at arm.com> 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.
>
> --
> Catalin

Reading through the full cover, they state clearly that rseq/vdso can't be used,
since it's ABI and the primary support candidate is Win32 ARM applications
under WINE on Linux. FEX just happens to get a benefit that it matches some
edge-case behaviour.

ARMv8 was introduced 15 years ago and there hasn't been a found use case
for this register yet. This sounds as good as any since it also matches ABI for
compatibility sake. Worst case instead of checking for TIF_32BIT, add some
prctl flag check with the same cost, allowing another 15 years to find another
use for this register.