Re: Clarification on necessary barriers before generating IPI

Will Deacon
2020-05-20T09:03:28Z

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.

Are you seeing a problem in practice?

Will