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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7b86aa90-6d64-589c-f11e-d2ee6ab3fd54@arm.com>
Date:   Mon, 10 Jun 2019 15:07:51 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Abel Vesa <abel.vesa@....com>
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>,
        Lucas Stach <l.stach@...gutronix.de>,
        Jacky Bai <ping.bai@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Leonard Crestez <leonard.crestez@....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 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:
>>>>> This is another alternative for the RFC:
>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F3%2F27%2F545&amp;data=02%7C01%7Cabel.vesa%40nxp.com%7C7cb2bda286214541bd1e08d6eda903e0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636957707535314247&amp;sdata=guYqyq5ND6HzW6doFyWrR1Ry4ffWpGwtm0xDZ2ufFSg%3D&amp;reserved=0
>>>>>
>>>>> This new workaround proposal is a little bit more hacky but more contained
>>>>> since everything is done within the irq-imx-gpcv2 driver.
>>>>>
>>>>> 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.

https://lkml.org/lkml/2019/3/27/1124 clearly says that 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.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...