Re: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.

[Robin Murphy <robin.murphy@arm.com>]

On 2020-06-05 14:02, Will Deacon wrote:
> On Fri, Jun 05, 2020 at 01:58:39PM +0100, Robin Murphy wrote:
>> On 2020-06-05 13:33, Will Deacon wrote:
>>> On Fri, Jun 05, 2020 at 01:10:29PM +0100, Mark Brown wrote:
>>>> On Mon, Jun 01, 2020 at 08:03:12AM +0100, Will Deacon wrote:
>>>>> On Fri, May 29, 2020 at 09:03:37AM +0000, Lixin (Victor, Kirin) wrote:
>>>>
>>>>>>      Intel optimized getcpu syscall on Linux/Android system by using vDSO, but
>>>>>>      ARM doesn't do any optimizations for getcpu syscall.
>>>>
>>>>>>      In Apple open source, TPIDRRO_EL0/TPIDRURO is used to save the CPU number,
>>>>>>      [1]https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/arm/cswitch.s.auto.html
>>>>
>>>>>>      �����������Is there any risk if using TPIDRRO_EL0/TPIDRURO to implement
>>>>>>      the vDSO for getcpu? Is there any possible to break any ARM ABI? Can you
>>>>>>      help us to confirm the considerations?
>>>>
>>>>> Do you have a use-case for high-performance getcpu() that isn't better
>>>>> suited to rseq()?
>>>>
>>>> I actually have an implementation of this that I'd been waiting for the
>>>> end of the merge window to post, largely because I first heard of the
>>>> use of restartable sequences for this after I'd already implemented the
>>>> vDSO version - this stuff is not as discoverable as one might desire.
>>>> It doesn't store the CPU ID directly in TPIDRRO but rather uses TPIDDRRO
>>>> to store the offset of a per-CPU struct in the vDSO data in order to
>>>> allow for the addition of further data in the future.  I'll post it
>>>> today for discussion.
>>>>
>>>> The latest version of the Mathieu's glibc integration patches is:
>>>>
>>>>       https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficios.com/
>>>>
>>>> The only things I can see where the vDSO does better are support for the
>>>> node parameter of getcpu() and the ease of implementation for the users,
>>>> the restartable sequences code was merged all the way back in v4.18 and
>>>> it's still not used by any of the libcs as far as I can see.  The node
>>>> to CPU mapping is static so I'm not sure how exciting that is, it could
>>>> be looked up separately when processing data if it's important, but the
>>>> ease of use feels like something.
>>>>
>>>> One important caveat with using TPIDRRO is that if KPTI is active then
>>>> the KPTI trampoline uses TPIDRRO as a scratch register so unless we can
>>>> find another register for scratch usage the user would need to give up
>>>> the protections offered by KPTI or run on future hardware which can use
>>>> E0PD instead.  This severely limits the usefulness on current systems.
>>>
>>> We only trash TPIDRRO on entry, so I think you could repopulate it on every
>>> exception from userspace and it *should* work with KPTI (famous last words!)
>>
>> Is that not already the case given that we keep TLS gubbins in there for
>> compat tasks?
> 
> No; we only trash TPIDRRO for 64-bit tasks. 32-bit tasks have loads of
> free registers :D

Derp, I thought that was one that we always rewrote somewhere in the 
exception return path, but I must have got muddled up with CONTEXTIDR 
(which upon double-checking, I see we 'restore' from itself, so I didn't 
even remember that quite right...)

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel