[PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

Nicholas Piggin npiggin at gmail.com
Fri Mar 16 21:46:47 AEDT 2018


On Fri, 16 Mar 2018 10:15:49 +0100
Michal Suchánek <msuchanek at suse.de> wrote:

> Hello,
> 
> On Fri, 16 Mar 2018 15:18:23 +1000
> Nicholas Piggin <npiggin at gmail.com> wrote:
> 
> > On Thu, 15 Mar 2018 20:15:52 +0100
> > Michal Suchanek <msuchanek at suse.de> wrote:
> >   
> > > On powerpc syscall entry is done in assembly so patch in an explicit
> > > barrier_nospec.    
> > 
> > Same comment as Linus for this -- the barriers are before the branch
> > here, so is it possible the branch instruction can be speculative
> > while the index is used to load the syscall table?  
> 
> As far as I understand barriers they separate code before the barrier
> and code after the barrier.
> 
> So inserting barrier_nospec after cmpldi means that the result of the
> cmpldi has to be known before any instruction following barrier_nospec
> that depends on the result can be executed. 
> 
> In many cases it is useful to put the barrier after a branch. It allows
> the compiler to speculate on the computed value at compile time and if
> it is constrained optimize out the branch. It may also result in the
> need to include many barriers and less readable code.
> 
> However, you have probably knowledge of the powerpc implementation of
> the barrier so if the semantic is actually different then please
> enlighten me.

I actually don't. I'm assuming we should be able to say that no previous
instruction is speculative when a subsequent one is executed.

But the branch instruction itself that is speculated, not the compare.

Usually even if all sources are ready, the pipeline may take in some
cycles after a branch, before that branch can finish executing and
squash speculation if it was wrong. Perhaps there is only a couple of
cycles of instructions that get a chance to reach execution units and
disturb any caches, but still there could be some window and I don't
think we would have architectural gurantees on that.

I'll try to ask around and see if there's any documentation we can
give you yet.

Thanks,
Nick


More information about the Linuxppc-dev mailing list