linux-kernel - Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

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 for Android: free password hash cracker in your pocket

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

Message-ID: <VI1PR04MB5055A808A08A1C47784E4332EE130@VI1PR04MB5055.eurprd04.prod.outlook.com>
Date:   Mon, 10 Jun 2019 14:32:37 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     Marc Zyngier <marc.zyngier@....com>, Abel Vesa <abel.vesa@....com>,
        Lucas Stach <l.stach@...gutronix.de>
CC:     Mark Rutland <mark.rutland@....com>,
        Abel Vesa <abelvesa@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jacky Bai <ping.bai@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        dl-linux-imx <linux-imx@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Carlo Caione <ccaione@...libre.com>
Subject: Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> On 10/06/2019 14:55, Abel Vesa wrote:
>> On 19-06-10 14:39:02, Marc Zyngier wrote:
>>> On 10/06/2019 14:29, Abel Vesa wrote:
>>>> On 19-06-10 14:19:21, Mark Rutland wrote:
>>>>> On Mon, Jun 10, 2019 at 03:13:44PM +0300, Abel Vesa wrote:

>>>>>> Basically, it 'hijacks' the registered gic_raise_softirq __smp_cross_call
>>>>>> handler and registers instead a wrapper which calls in the 'hijacked'
>>>>>> handler, after that calling into EL3 which will take care of the actual
>>>>>> wake up. This time, instead of expanding the PSCI ABI, we use a new vendor SIP.
>>>>>
>>>>> IIUC from last time [1,2], this erratum affects all interrupts
>>>>> targetting teh idle CPU, not just IPIs, so even if the bodge is more
>>>>> self-contained, it doesn't really solve the issue, and there are still
>>>>> cases where a CPU will not be woken from idle when it should be (e.g.
>>>>> upon receipt of an LPI).
>>>>
>>>> Wrong, this erratum does not affect any other type of interrupts, other
>>>> than IPIs. That is because all the other interrupts go through GPC,
>>>> which means the cores will wake up on any other type (again, other than IPI).
>>>
>>> Huh... Are you saying that LPIs and PPIs are going through the GPC, and
>>> will trigger the wake-up of the core? That's not the conclusion we
>>> reached last time.
>>
>> Hmm, I don't think that was the conclusion. Yes, Lucas was saying (IIRC)
>> that if you terminate the IRQs at GIC then all the other interrupts will be
>> in the same situation. But the performance improvement given by terminating
>> them at GIC might not be worth it when compared to the cpuidle support.
> 
> PPIs are broken,
> relying on some other terrible hack for the timer (and only the timer,
> leaving other PPIs dead as a nail). It also implies that LPIs have never
> been looked into, and given that they aren't routed through the GPC, the
> conclusion is pretty easy to draw.
> 
> Nobody is talking about performance here. It is strictly about
> correctness, and what I read about this system is that it cannot
> reliably use cpuidle.
My argument was that it's fine if PPIs and LPIs are broken as long as 
they're not used:

  * PPIs are only used for local timer which is not used for wakeup.
  * LPIs on imx are not currently implemented.

This workaround is only targeted at a very specific SOC with specific 
usecases and in that context it behaves correctly, as far as I can tell.

As mentioned in another thread the HW issue was already solved in newer 
chips of the same family (like imx8mm). If there is a need for PPIs and 
LPIs on imx8mq in the future then maybe we can detect that scenario and 
disable cpuidle?

--
Regards,
Leonard