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

[Guilherme G. Piccoli]

On 09/09/2026 15:38, Catalin Marinas wrote:
> Hi Guilherme,
> [...] 
>>
>> 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.
> 
> [...] 
> 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.
> 

Hi Catalin, thanks for your response! It covers all points, thanks for
detailing / explaining things.

Well, Wine cannot trap instructions like that, so in case an arm64
application is running on Linux and reads TPIDRRO, currently it gets 0
anyways. Nothing we can do from Wine side AFAIU.

I understand our use case isn't strong enough to lock this register's
ABI from your/Will's perspective, so we discussed internally and will
try to hold the patch downstream then.
Cheers,


Guilherme