Re: Clarification on necessary barriers before generating IPI

Linu Cherian
2020-05-20T17:37:39Z

Hi Will,

On Wed, May 20, 2020 at 2:33 PM Will Deacon <will@kernel.org> wrote:
>
> On Wed, May 20, 2020 at 02:23:25PM +0530, Linu Cherian wrote:
> > On Wed, May 20, 2020 at 1:59 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Wed, May 20, 2020 at 01:38:24PM +0530, Linu Cherian wrote:
> > > > How is it ensured that system register write using msr instruction(gic_send_sgi)
> > > > doesnt get reordered before the stores to IPI call processing
> > > > list(call_single_queue in kernel/smp.c), so that IPI is guaranteed to
> > > > be generated after the stores get completed.
> > >
> > > I think the flow is:
> > >
> > > <store to memory>
> > > DSB ST
> >
> > Dont we need an extra ISB here to ensure that the subsequent MSR SGI1R doesnt
> > get executed before <store to memory> and DSB ST ?
> >
> > This is on the assumption that DSB ST doesnt enforce the ordering of MSR SGI1R.
>
> I don't think that's a valid assumption. The architecture says:
>
> | A DSB instruction executed by a PE, PEe, completes when [...] all explicit
> | memory accesses of the required access types appearing in program order
> | before the DSB are complete for the set of observers in the required
> | shareability domain.
>
> and:
>
> | In addition, no instruction that appears in program order after the DSB
> | instruction can alter any state of the system or perform any part of its
> | functionality until the DSB completes other than:
> |
> | * Being fetched from memory and decoded.
> | * Reading the general-purpose, SIMD and floating-point, Special-purpose, or
> | System registers that are directly or indirectly read without causing
> | side-effects.
>

Thats clear. Thanks.

> Are you seeing a problem in practice?
>

Just came across this code, while trying to debug something related.
Will let you know if i have further followup.

> Will