lkml.org 
[lkml]   [2018]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry
    On Fri, 16 Mar 2018 10:15:49 +0100
    Michal Suchánek <msuchanek@suse.de> wrote:

    > Hello,
    >
    > On Fri, 16 Mar 2018 15:18:23 +1000
    > Nicholas Piggin <npiggin@gmail.com> wrote:
    >
    > > On Thu, 15 Mar 2018 20:15:52 +0100
    > > Michal Suchanek <msuchanek@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

    \
     
     \ /
      Last update: 2018-03-16 11:47    [W:2.519 / U:0.348 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site