On 19/09/2025 12:56, Will Deacon wrote:

On Fri, Sep 19, 2025 at 12:49:22PM +0100, Ryan Roberts wrote:

quoted

On 19/09/2025 12:27, Will Deacon wrote:

quoted

On Fri, Sep 19, 2025 at 11:08:47AM +0100, Ryan Roberts wrote:

quoted

On 18/09/2025 22:10, Will Deacon wrote:

quoted

On Wed, 17 Sep 2025 12:02:06 -0700, Yang Shi wrote:

quoted

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.

quoted

quoted

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