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

From: Will Deacon <will@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "fujun \(F\)" <oliver.fu@hisilicon.com>,
	Mark Brown <broonie@kernel.org>,
	Wuxuecheng <wuxuecheng@hisilicon.com>,
	"Lixin \(Victor, Kirin\)" <victor.lixin@hisilicon.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.
Date: Fri, 5 Jun 2020 14:02:52 +0100	[thread overview]
Message-ID: <20200605130251.GB20441@willie-the-truck> (raw)
In-Reply-To: <a46ddb53-2226-c9c3-bf3f-0fcc5d924b1e@arm.com>

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

Will

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