From: Ohad Ben-Cohen <ohad@wizery.com>
To: Lina Iyer <lina.iyer@linaro.org>
Cc: "Anna, Suman" <s-anna@ti.com>,
Bjorn Andersson <Bjorn.Andersson@sonymobile.com>,
Andy Gross <agross@codeaurora.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Jeffrey Hugo <jhugo@codeaurora.org>
Subject: Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock
Date: Sat, 23 May 2015 10:35:44 +0300 [thread overview]
Message-ID: <CAK=Wgba0BVZLTJb7SYTX_NJhd46DkW-w8uHSyWsRg=xqK7jArw@mail.gmail.com> (raw)
In-Reply-To: <20150518150302.GA23206@linaro.org>
Hi Lina,
On Mon, May 18, 2015 at 6:03 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> The lock in question is used differently than traditional locks across
> processors. This lock helps synchronizes context transition from
> non-secure to secure on the same processor.
>
> The usecase, goes like this. In cpuidle, any core can be the last core
> to power down. The last man also holds the responsibility of shutting
> down shared resources like caches etc. The way the power down of a core
> works is, there are some high level decisions made in Linux and these
> decisions (like to flush and invalidate caches) etc gets transferred
> over to the the secure layer. The secure layer executes the ARM WFI that
> powers down the cpu, but uses these decisions passed into to determine
> if the cache needs to be invalidated upon wakeup etc.
>
> There is a possible race condition between what Linux thinks is the last
> core, vs what secure layer thinks is the last core. Lets say, two cores
> c0, c1 are going down. c1 is the second last core to go down from Linux
> as such, will not carry information about shared resources when making
> the SCM call. c1 made the SCM call, but is stuck handling some FIQs. In
> the meanwhile c0, goes idle and since its the last core in Linux,
> figures out the state of the shared resources. c0 calls into SCM, and
> ends up powering down earlier than c1. Per secure layer, the last core
> to go down is c1 and the votes of the shared resources are considered
> from that core. Things like cache invalidation without flush may happen
> as a result of this inconsistency of last man view point.
>
> The way we have solved it, Linux acquires a hw spinlock for each core,
> when calling into SCM and the secure monitor releases the spinlock. At
> any given time, only one core can switch the context from Linux to
> secure for power down operations. This guarantees the last man is
> synchronized between both Linux and secure. Another core may be spinning
> waiting for hw mutex, but they all happen serialized. This mutex is held
> in an irq disable context in cpuidle.
>
> There may be another processor spining to wait on hw mutex, but there
> isnt much to do otherwise, because the only operation at this time while
> holding the lock is to call into SCM and that would unlock the mutex.
Just to make sure I understand, is this how your scenario is solved?
- c1 goes down
- c0 goes down, carries information about shared resources
- c1 takes HWLOCK and calls into SCM, stuck handling FIQs
- c0 wants to call into SCM but is waiting spinning on HWLOCK
- c1 completes handling FIQs, goes idle, HWLOCK is released by secure monitor
- c0 takes HWLOCK, calls into SCM, shared resources handled correctly,
HWLOCK in this example is a single shared hwspinlock accessible by c0,
c1 and secure monitor.
Thanks,
Ohad.
next prev parent reply other threads:[~2015-05-23 7:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 17:07 [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock Lina Iyer
2015-05-09 9:25 ` Ohad Ben-Cohen
2015-05-11 14:46 ` Lina Iyer
2015-05-16 9:03 ` Ohad Ben-Cohen
2015-05-18 15:03 ` Lina Iyer
2015-05-19 20:13 ` Andy Gross
2015-05-20 22:02 ` Lina Iyer
2015-05-23 7:35 ` Ohad Ben-Cohen [this message]
2015-05-26 20:36 ` Lina Iyer
2015-06-05 1:09 ` Ohad Ben-Cohen
2015-06-05 23:50 ` Jeffrey Hugo
2015-06-06 3:28 ` Ohad Ben-Cohen
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='CAK=Wgba0BVZLTJb7SYTX_NJhd46DkW-w8uHSyWsRg=xqK7jArw@mail.gmail.com' \
--to=ohad@wizery.com \
--cc=Bjorn.Andersson@sonymobile.com \
--cc=agross@codeaurora.org \
--cc=galak@codeaurora.org \
--cc=jhugo@codeaurora.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=s-anna@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).