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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 21 Jan 2016 16:48:57 +0800
From:	Zhaoyang Huang <zhaoyang.huang@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Zhaoyang Huang (黄朝阳) 
	<zhaoyang.huang@...eadtrum.com>,
	Catalin Marinas <catalin.marinas@....com>, will.deacon@....com,
	linux-kernel@...r.kernel.org, Hanjun Guo <hanjun.guo@...aro.org>,
	suzuki.poulose@....com
Subject: Re: [RFC PATCH v2] Add IPI entry for CPU UP

Hi Mark,
Do you have any suggestion on how to sync the GIC operation from
kernel and psci parallelly? Thanks!

On 12 January 2016 at 19:51, Mark Rutland <mark.rutland@....com> wrote:
> On Tue, Jan 12, 2016 at 09:38:20AM +0000, Lorenzo Pieralisi wrote:
>> On Tue, Jan 12, 2016 at 10:17:42AM +0800, Zhaoyang Huang wrote:
>> > On 12 January 2016 at 10:05, Zhaoyang Huang <zhaoyang.huang@...aro.org> wrote:
>> > > In some ARM SOCs, IPI interrupt is used for hotplug in one cpu, that is,
>> > > sending a IPI to the core in WFI and powerdown status. So Add a IPI
>> > > entry for handle this kind of cpu up interrupt
>> > > Launching the IPI can be done within PSCI, while there will be one unknown
>> > > type of IPI as the dest core come up to the kernel world which will bring a
>> > > warning so far.So add such type of IPI to handle the interrupt.
>>
>> You missed CC'ing ALKML for the second time and you were warned.
>>
>> You are adding a call to *send* an IPI in the kernel so the commit
>> above is misleading.
>>
>> Acknowledge and clear the IRQ in FW so that the mechanism is completely
>> implemented in FW (ie PSCI), that the CPU coming out of reset will run
>> before getting to the kernel, this patch is not needed and we already
>> explained to you why.
>>
>> Lorenzo
>
> I would also suggest that FW used the set of SGIs reserved for secure
> usage (i.e. ID8 - ID15), as these will not conflict with those the
> kernel uses.
>
> Thanks,
> Mark.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ