From: Will Deacon <will@kernel.org>
To: Linu Cherian <linuc.decode@gmail.com>
Cc: maz@kernel.org, Linu Cherian <lcherian@marvell.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Clarification on necessary barriers before generating IPI
Date: Wed, 20 May 2020 10:03:18 +0100 [thread overview]
Message-ID: <20200520090317.GD24293@willie-the-truck> (raw)
In-Reply-To: <CAAHhmWhum+s5OopKMcNOqvGN5aYek-BJRseN8wS47LiH+hJcKg@mail.gmail.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-20 9:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 8:08 Clarification on necessary barriers before generating IPI Linu Cherian
2020-05-20 8:28 ` Will Deacon
2020-05-20 8:53 ` Linu Cherian
2020-05-20 9:03 ` Will Deacon [this message]
2020-05-20 17:37 ` Linu Cherian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200520090317.GD24293@willie-the-truck \
--to=will@kernel.org \
--cc=lcherian@marvell.com \
--cc=linuc.decode@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox