From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752811AbcAVIAc (ORCPT <rfc822;w@1wt.eu>);
	Fri, 22 Jan 2016 03:00:32 -0500
Received: from foss.arm.com ([217.140.101.70]:54616 "EHLO foss.arm.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752748AbcAVIAP (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 22 Jan 2016 03:00:15 -0500
Date: Fri, 22 Jan 2016 08:07:08 +0000
From: Marc Zyngier <marc.zyngier@arm.com>
To: Zhaoyang Huang <zhaoyang.huang@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        "Zhaoyang Huang (=?UTF-8?B?6buE5pyd6Ziz?=)" 
	<zhaoyang.huang@spreadtrum.com>,
        Catalin Marinas <catalin.marinas@arm.com>, will.deacon@arm.com,
        linux-kernel@vger.kernel.org, Hanjun Guo <hanjun.guo@linaro.org>,
        suzuki.poulose@arm.com
Subject: Re: [RFC PATCH v2] Add IPI entry for CPU UP
Message-ID: <20160122080708.0b7efde9@why.wild-wind.fr.eu.org>
In-Reply-To: <CAN2waFuJDqPiG4tmn8Q2pKTkEoh8sDTVDefQZdXnr6PFO+bk4w@mail.gmail.com>
References: <1452564312-1265-1-git-send-email-zhaoyang.huang@spreadtrum.com>
	<CAN2waFuaVesBB6SSpuQ8-_bF0hZ1C56NX=CR5z06ytVLccnnbA@mail.gmail.com>
	<20160112093820.GA3601@red-moon>
	<20160112115104.GB4858@leverpostej>
	<CAN2waFsHWrEFCTdStMTsW2h2pMMPEtiHxDV1yc6cWPZ60qGiZA@mail.gmail.com>
	<20160121104905.GA2581@leverpostej>
	<CAN2waFuJDqPiG4tmn8Q2pKTkEoh8sDTVDefQZdXnr6PFO+bk4w@mail.gmail.com>
Organization: ARM Ltd
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 22 Jan 2016 10:01:24 +0800
Zhaoyang Huang <zhaoyang.huang@linaro.org> wrote:

> On 21 January 2016 at 18:51, Mark Rutland <mark.rutland@arm.com>
> wrote:
> > On Thu, Jan 21, 2016 at 04:48:57PM +0800, Zhaoyang Huang wrote:
> >> Hi Mark,
> >
> > Hi,
> >
> >> Do you have any suggestion on how to sync the GIC operation from
> >> kernel and psci parallelly? Thanks!
> >
> > I'm not sure what you mean.
> >
> > What problem are you having with synchronising GIC accesses?
> >
> > As far as I can see, the CPU sending the IPI can simply poke the
> > relevant register in the distributor without requiring any
> > synchronisation. The CPU receiving the IPI is the only CPU with
> > access to its CPU interface.
> >
> > Could you describe your problem in more detail?
> >
> > Thanks,
> > Mark.
> >
> Hi Mark,
> Sorry for making confusions. I mean mutex between kernel and trustzone
> when accessing
> GIC registers. It is possible for they two issuing an accessing to the
> same register at the
> same time. How should I handle such kind of race conditions?

The GIC programming interface is designed to allow this kind of access
without locking:

- CPU interface: the CPU cannot be in secure and non-secure at the same
  time, so there is no race for the access. Furthermore, the fact that
  secure interrupts have a higher priority than non-secure ones ensure
  that a secure interrupt will preempt a non-secure one, making the
  whole thing race free.

- Distributor: Writing to the GICD_SGIR register is atomic, and the GIC
  will ensure simultaneous access.

In a nutshell, there is no need to worry about these things, because
the GIC architecture has been designed from the ground up to support
this.

See for example this:
http://git.denx.de/?p=u-boot.git;a=blob_plain;f=arch/arm/cpu/armv7/sunxi/psci_sun7i.S;hb=HEAD

which uses IPIs to implement PSCI on an existing ARMv7 system.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.