Date:	Tue, 26 May 2015 14:36:34 -0600
From:	Lina Iyer <lina.iyer@...aro.org>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	"Anna, Suman" <s-anna@...com>,
	Bjorn Andersson <Bjorn.Andersson@...ymobile.com>,
	Andy Gross <agross@...eaurora.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kumar Gala <galak@...eaurora.org>,
	Jeffrey Hugo <jhugo@...eaurora.org>
Subject: Re: [PATCH RFC] hwspinlock: Don't take software spinlock before
 hwspinlock

On Sat, May 23 2015 at 01:36 -0600, Ohad Ben-Cohen wrote:
>Hi Lina,
>
>On Mon, May 18, 2015 at 6:03 PM, Lina Iyer <lina.iyer@...aro.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.
>
That is correct.

-- Lina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists