linux-kernel - Re: [RFC PATCH] Add IPI entry for CPU UP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160111113756.GJ6499@leverpostej>
Date:	Mon, 11 Jan 2016 11:37:57 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Zhaoyang Huang <zhaoyang.huang@...aro.org>
Cc:	Zhaoyang Huang (黄朝阳) 
	<Zhaoyang.Huang@...eadtrum.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	"will.deacon@....com" <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>
Subject: Re: [RFC PATCH] Add IPI entry for CPU UP

On Mon, Jan 11, 2016 at 07:21:32PM +0800, Zhaoyang Huang wrote:
> On 11 January 2016 at 19:03, Mark Rutland <mark.rutland@....com> wrote:
> > On Mon, Jan 11, 2016 at 10:55:08AM +0000, Zhaoyang Huang (黄朝阳) wrote:
> >> In fact, this patch is related to the counterpart of the PSCI code in
> >> kernel world which you mentioned before. In SPRD's SOC, we have to
> >> implement a way of "wakeup" the core in powerdown state, which is to
> >> launch a IPI to the dest core.
> >
> > This is not required with PSCI, which abstracts the wakeup and power
> > management behind the CPU_ON call.
> >
> > The kernel should only have to issue a CPU_ON call, and the firmware
> > should do the right thing behind the scenes (e.g. enabling power to the
> > core, sending an IPI if necessary).
> >
> > If the kernel needs to do anything other than issue a CPU_ON call, this
> > is not PSCI.
> >
> >> The reason why we can not accessing power related register to light on
> >> the core is the state machine of the PMU will not be safe for this
> >> scenario.
> >
> > I'm not sure I understand.
> >
> > Which software agent (kernel? firmware?) cannot access this PMU
> > register, and why?
> >
> > What is the problem with the PMU state machine?
> >
> With regarding to the cpu down, we use a so called "auto power down"
> mode, which have the PMU power down the core after it detect WFI
> status(in fact, it is the same method for cpu suspend for our SOC). By
> using this kind of method of power down, we have to use the method
> which I mentioned above for power on.

Even if you need an IPI to bring the CPU back online, I don't see why
this needs to be in the kernel. That can (and must) be done in the
firmware, hidden behind the PSCI interface.

The logical flow should be:

  CPU x: Kernel calls PSCI CPU_OFF
  CPU x: PSCI FW puts core in "auto power down" mode
  CPU x: PSCI FW issues a WFI
  CPU x: offline

  CPU y: Kernel calls PSCI CPU_ON for CPU x
  CPU y: PSCI FW sets up power controller
  CPU y: PSCI FW issues IPI to CPU x
  CPU y: PSCI FW waits for CPU x to come online

  CPU x: comes online
  CPU y: Returns to kernel

  CPU x: initialised by FW
  CPU x: enters kernel at provided entry point

Note that from the kernel's PoV, it only needs to call CPU_ON and
CPU_OFF.

> In fact, we have ever used another method of on/off, which have NOT
> the issue of launch IPI(we call it as force shutdown). But it has some
> stability problem for cpu on(PC will run out of range. ASIC engineers
> ask us to switch to auto mode to solve it)

I don't think this is relevant. See above.

I assume that the core is only placed in "auto power down" mode in the
firmware immediately before the WFI (i.e. a WFI in the kernel will not
trigger a power down spuriously)?

Thanks,
Mark.