Message-ID: <38fa4717-9105-4bca-a2cd-914afc109570@arm.com>
Date: Fri, 19 Sep 2025 13:00:49 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: Will Deacon <will@...nel.org>
Cc: catalin.marinas@....com, akpm@...ux-foundation.org, david@...hat.com,
 lorenzo.stoakes@...cle.com, ardb@...nel.org, dev.jain@....com,
 scott@...amperecomputing.com, cl@...two.org,
 Yang Shi <yang@...amperecomputing.com>, kernel-team@...roid.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block
 mapping when rodata=full

On 19/09/2025 12:56, Will Deacon wrote:
> On Fri, Sep 19, 2025 at 12:49:22PM +0100, Ryan Roberts wrote:
>> On 19/09/2025 12:27, Will Deacon wrote:
>>> On Fri, Sep 19, 2025 at 11:08:47AM +0100, Ryan Roberts wrote:
>>>> On 18/09/2025 22:10, Will Deacon wrote:
>>>>> On Wed, 17 Sep 2025 12:02:06 -0700, Yang Shi wrote:
>>>>>> On systems with BBML2_NOABORT support, it causes the linear map to be mapped
>>>>>> with large blocks, even when rodata=full, and leads to some nice performance
>>>>>> improvements.
>>>>>>
>>>>>> Ryan tested v7 on an AmpereOne system (a VM with 12G RAM) in all 3 possible
>>>>>> modes by hacking the BBML2 feature detection code:
>>>>>>
>>>>>> [...]
>>>>>
>>>>> Applied patches 1 and 3 to arm64 (for-next/mm), thanks!
>>>>>
>>>>> [1/5] arm64: Enable permission change on arm64 kernel block mappings
>>>>>       https://git.kernel.org/arm64/c/a660194dd101
>>>>> [3/5] arm64: mm: support large block mapping when rodata=full
>>>>>       https://git.kernel.org/arm64/c/a166563e7ec3
>>>>>
>>>>> I also picked up the BBML allow-list addition (second patch) on
>>>>> for-next/cpufeature.
>>>>>
>>>>> The fourth patch ("arm64: mm: split linear mapping if BBML2 unsupported
>>>>> on secondary CPUs") has some really horrible conflicts. These are partly
>>>>> due to some of the type cleanups on for-next/mm but I think mainly due
>>>>> to Kevin's kpti rework that landed after -rc1.
>>>>
>>>> Thanks Will, although I'm nervous that without this patch, some platforms might
>>>> not boot; Wikipedia tells me that there are some Google, Mediatek and Qualcomm
>>>> SoCs that pair X4 CPUs (which is on the BBML2_NOABORT allow list) with A720
>>>> and/or A520 (which are not). See previous mail at [1].
>>>
>>> I'd be surprised if these SoCs are booting on the X4 but who knows.
>>
>> Ahh. You can probably tell I'm a bit naive to some of this system level stuff...
>> I had assumed they would want to boot on the big CPU to reduce boot time.
> 
> One of the problems is that the boot CPU becomes CPU0 and that inevitably
> means it ends up being responsible for a tonne of extra stuff (interrupts,
> TZ, etc) and in many cases can't be offlined. So it's all a trade-off.
> 
>>> Lemme have another look at applying the patch with fresh eyes, but I do
>>> wonder whether having X4 on the allow list really makes any sense. Are
>>> there any SoCs out there that _don't_ pair it with CPUs that aren't on
>>> the allow list? (apologies for the double negative).
>>
>> Hmm, that's a fair question. I'm not aware of any. So I guess the simplest
>> solution is to remove X4 from the allow list and ditch fourth patch.
> 
> That's probably a good idea but I have a horrible feeling we _are_ going
> to need your patch once the errata start flying about :)
> 
> So how about we:
> 
>   - Remove X4 from the list
>   - I try harder to apply your patch for secondary CPUs...
>   - ... if I fail, we can apply it next time around
> 
> Sound reasonable?

Yeah that works for me. Cheers!

> 
> Will

Powered by blists - more mailing lists