Re: [PATCH 1/6] ARM: spectre-bhb: enable for Cortex-A15

[Jon Hunter <jonathanh@nvidia.com>]

On 24/05/2022 16:21, Ard Biesheuvel wrote:
> On Tue, 24 May 2022 at 16:50, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> Hi Ard,
>>
>> On 28/03/2022 14:47, Ard Biesheuvel wrote:
>>> The Spectre-BHB mitigations were inadvertently left disabled for
>>> Cortex-A15, due to the fact that cpu_v7_bugs_init() is not called in
>>> that case. So fix that.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>> ---
>>>    arch/arm/mm/proc-v7-bugs.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
>>> index 06dbfb968182..fb9f3eb6bf48 100644
>>> --- a/arch/arm/mm/proc-v7-bugs.c
>>> +++ b/arch/arm/mm/proc-v7-bugs.c
>>> @@ -288,6 +288,7 @@ void cpu_v7_ca15_ibe(void)
>>>    {
>>>        if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(0)))
>>>                cpu_v7_spectre_v2_init();
>>> +     cpu_v7_spectre_bhb_init();
>>>    }
>>>
>>>    void cpu_v7_bugs_init(void)
>>
>>
>> Since this patch has been merged, I am seeing a ton of messages when
>> booting Linux on tegra124-jetson-tk1 ...
>>
> 
> Thanks for the report. The good news is that the Spectre BHB
> protection is finally taking effect on your system.
> 
>> [ 1233.327547] CPU0: Spectre BHB: using loop workaround
>> [ 1233.327795] CPU1: Spectre BHB: using loop workaround
>> [ 1233.328270] CPU1: Spectre BHB: using loop workaround
>> [ 1233.328700] CPU1: Spectre BHB: using loop workaround
>> [ 1233.355477] CPU2: Spectre BHB: using loop workaround
>> ** 7 printk messages dropped **
>> [ 1233.366271] CPU0: Spectre BHB: using loop workaround
>> [ 1233.366580] CPU0: Spectre BHB: using loop workaround
>> [ 1233.366815] CPU1: Spectre BHB: using loop workaround
>> [ 1233.405475] CPU1: Spectre BHB: using loop workaround
>> [ 1233.405874] CPU0: Spectre BHB: using loop workaround
>> [ 1233.406041] CPU1: Spectre BHB: using loop workaround
>> ** 1 printk messages dropped **
>>
>> This is significantly increasing the boot time and causing failures if
>> the boot takes too long.
>>
>> I see that Dmitry has posted a fix for one of these cases [0], but the
>> above also needs to be fixed.
>>
> 
> Agreed.
> 
> Do we have any idea why this init hook is being called so often? Is
> this expected on systems that do agressive suspend/resume for power
> management, or is there another existing issue here that is just
> coming to light due to the newly added printk() ?


So far I have not dug any further, but I do know it is not doing any 
aggressive suspend/resume. From what Dmitry indicated he saw this during 
CPU idle transitions and this platform would definitely by exercising 
CPU idle.

Jon

-- 
nvpublic