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

From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: "fujun \(F\)" <oliver.fu@hisilicon.com>,
	Wuxuecheng <wuxuecheng@hisilicon.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Lixin \(Victor, Kirin\)" <victor.lixin@hisilicon.com>
Subject: Re: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.
Date: Fri, 5 Jun 2020 13:33:03 +0100	[thread overview]
Message-ID: <20200605123302.GA19936@willie-the-truck> (raw)
In-Reply-To: <20200605121029.GE5413@sirena.org.uk>

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!)

Will

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