Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751600AbbEZUgj (ORCPT ); Tue, 26 May 2015 16:36:39 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:35860 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbbEZUgg (ORCPT ); Tue, 26 May 2015 16:36:36 -0400 Date: Tue, 26 May 2015 14:36:34 -0600 From: Lina Iyer To: Ohad Ben-Cohen Cc: "Anna, Suman" , Bjorn Andersson , Andy Gross , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Kumar Gala , Jeffrey Hugo Subject: Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock Message-ID: <20150526203634.GL23206@linaro.org> References: <1430500026-47990-1-git-send-email-lina.iyer@linaro.org> <20150511144608.GB16124@linaro.org> <20150518150302.GA23206@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3216 Lines: 61 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/