[RFC PATCH v6 0/4] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full

[Ryan Roberts]

Hi Yang,

Sorry for slow reply; for some reason this didn't make it to my mailbox, then
I've been out on holiday for 2 weeks.


On 05/08/2025 19:37, Yang Shi wrote:
> Hi Ryan
> 
> On 8/5/25 1:13 AM, Ryan Roberts wrote:
>> Hi All,
>>
>> This is a new version built on top of Yang Shi's work at [1]. Yang and I have
>> been discussing (disagreeing?) about the best way to implement the last 2
>> patches. So I've reworked them and am posting as RFC to illustrate how I think
>> this feature should be implemented, but I've retained Yang as primary author
>> since it is all based on his work. I'd appreciate feedback from Catalin and/or
>> Will on whether this is the right approach, so that hopefully we can get this
>> into shape for 6.18.
>>
>> The first 2 patches are unchanged from Yang's v5; the first patch comes from Dev
>> and the rest of the series depends upon it.
> 
> Thank you for making the prototype and retaining me as primary author. The
> approach is basically fine to me. But there are some minor concerns. Some of
> them were raised in the comment for patch #3 and patch #4. I put them together
> here.
>     1. Walk page table twice. This has been discussed before. It is not very
> efficient for small split, for example, 4K. Unfortunately, the most split is
> still 4K in the current kernel AFAICT.

I have added a solution to this in my current version; to solve the mutex
problem, I've ended up passing both start and end to the main split() function
then have a helper function which the parent calls twice. With that I can avoid
the second call if the (end - start) is PAGE_SIZE - I just call split() once
with the "lesser aligned" of the 2 addresses and that guarantees that the page
is mapped by PTE. Added as it's own optimization patch.

>         Hopefully this can be mitigated by some new development, for example,
> ROX cache.
>     2. Take mutex lock twice and do lazy mmu twice. I think it is easy to
> resolve as I suggested in patch #3.

Yep, I've fixed this, as per above.

>     3. Walk every PTE and call split on every PTE for repainting. It is not very
> efficient, but may be ok for repainting since it is just called once at boot time.

I've added an optimization patch to avoid splitting to contpmd/contpte in this
case and we can additionally avoid visiting the pte table at all if it was
created by splitting a pmd.

> 
> I don't think these concerns are major blockers IMHO. Anyway let's see what
> Catalin and/or Will think about this.

I've additionally done some more cleanup; most notably I've removed the
bbml2_ptes[] array to save those 5 pages. Instead, I'm reusing the same flag
that kpti uses.

Functional tests all look good. I'll run some benchmarks overnight and if all
looks good, I'll post by the end of the week.

Hopefully Catalin or Will can provide some comments for this version.

Thanks,
Ryan

> 
> Regards,
> Yang