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: <0c023990-4482-fc42-30ba-3e801693dbec@posteo.de>
Date:   Wed, 30 Oct 2019 09:14:11 +0100
From:   Martin Kepplinger <martink@...teo.de>
To:     Abel Vesa <abel.vesa@....com>
Cc:     Abel Vesa <abelvesa@...il.com>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        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>,
        Marc Zyngier <marc.zyngier@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Jacky Bai <ping.bai@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Carlo Caione <ccaione@...libre.com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

On 30.10.19 09:08, Abel Vesa wrote:
> On 19-10-30 07:11:37, Martin Kepplinger wrote:
>> On 23.06.19 13:47, Martin Kepplinger wrote:
>>> On 10.06.19 14:13, 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%7Cf5f8d8dd37974234fcb108d75d000944%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637080127051582184&amp;sdata=qZEo1fY1lkTjqZWuuQftYJ5euEsSxjEAqGILCY8ChnU%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.
>>>>
>>>> I also have the patches ready for TF-A but I'll hold on to them until I see if
>>>> this has a chance of getting in.
>>>
>>
>> Hi Abel,
>>
>> Running this workaround doesn't seem to work anymore on 5.4-rcX. Linux
>> doesn't boot, with ATF unchanged (includes your workaround changes). I
>> can try to add more details to this...
>>
> 
> This is happening because the system counter is now enabled on 8mq.
> And since the irq-imx-gpcv2 is using as irq_set_affinity the 
> irq_chip_set_affinity_parent. This is because the actual implementation
> of the driver relies on GIC to set the right affinity. On a SoC
> that has the wake_request signales linked to the power controller this
> works fine. Since the system counter is actually the tick broadcast
> device and the set affinity relies only on GIC, the cores can't be
> woken up by the broadcast interrupt.
> 
>> Have you tested this for 5.4? Could you update this workaround? Please
>> let me know if I missed any earlier update on this (having a cpu-sleep
>> idle state).
>>
> 
> The solution is to implement the set affinity in the irq-imx-gpcv2 driver
> which would allow the gpc to wake up the target core when the broadcast
> irq arrives.
> 
> I have a patch for this. I just need to clean it up a little bit.
> Unfortunately, it won't go upstream since everuone thinks the gic
> should be the one to control the affinity. This obviously doesn't work
> on 8mq.

I see and that's fine for the moment.

> 
> Currently, I'm at ELCE in Lyon. Will get back at the office tomorrow
> and sned you what I have.
> 

Thanks for answering so quickly. I'll test as soon as you can send that
update.

thanks for this work,

                                martin