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

[Catalin Marinas <catalin.marinas@arm.com>]

Hi Guilherme,

On Mon, Aug 17, 2026 at 11:48:28AM -0300, Guilherme G. Piccoli wrote:
> 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.

One example is Mark's patchset from 2020 you mentioned. While they were
intended as a fast getcpu(), the idea for TPIDRRO was to hold some
offset into a data structure rather than the raw smp_processor_id() (for
future expansion, e.g. task pid). In the meantime we got rseq and never
continued that series.

TBH, I think the Wine or FEX use-case is fairly narrow to give up on
other potential uses for TPIDRRO.

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

It might be a thread or CPU specific value but without any guaranteed
ABI to be read directly. Something to be used internally by the vDSO.

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

No, that's bad ABI to depend on Kconfig or prctl() for different views
of this register.

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

Yes, and we have other parties interested in this register for more vDSO
uses. IIUC, you'd not be able to use a getcpu() vDSO implementation
either, so it won't help you.

Not really familiar with Wine but can it not implement
GetCurrentProcessorNumber() using rseq? Or do you try to handle actual
MRS directly? If the latter, any way to patch the instruction to a BRK
and handle the trap? If it's on a fast path, can you branch to a stub
that reads the rseq cpu id (offset from TPIDR) and branches back? You'd
need one stub per MRS.

-- 
Catalin