Re: [RFC V1 00/16] arm64/mm: Enable 128 bit page table entries

Anshuman Khandual
2026-04-09T02:08:30Z

On 08/04/26 5:43 PM, David Hildenbrand (Arm) wrote:
> On 4/8/26 12:53, Anshuman Khandual wrote:
>> On 07/04/26 8:14 PM, David Hildenbrand (Arm) wrote:
>>> On 2/24/26 06:11, Anshuman Khandual wrote:
>>>> FEAT_D128 is a new arm architecture feature adding support for VMSAv9-128
>>>> translation system. FEAT_D128 is an optional feature from ARMV9.3 onwards.
>>>> So with this feature arm64 platforms could have two different translation
>>>> systems, VMSAv8-64 and VMSAv9-128 could selectively be enabled.
>>>>
>>>> FEAT_D128 adds 128 bit page table entries, thus supporting larger physical
>>>> and virtual address range while also expanding available room for more MMU
>>>> management feature bits both for HW and SW.
>>>>
>>>> This series has been split into two parts. Generic MM changes followed by
>>>> arm64 platform changes, finally enabling D128 with a new config ARM64_D128.
>>>>
>>>> READ_ONCE() on page table entries get routed via level specific pxdp_get()
>>>> helpers which platforms could then override when required. These accessors
>>>> on arm64 platform help in ensuring page table accesses are performed in an
>>>> atomic manner while reading 128 bit page table entries.
>>>>
>>>> All ARM64_VA_BITS and ARM64_PA_BITS combinations for all page sizes are now
>>>> supported both on D64 and D128 translation regimes. Although new 56 bits VA
>>>> space is not yet supported. Similarly FEAT_D128 skip level is not supported
>>>> currently.
>>>>
>>>> Basic page table geometry has been changed with D128 as there are now fewer
>>>> entries per level. Please refer to the following table for leaf entry sizes
>>>>
>>>> D64 D128
>>>> ------------------------------------------------
>>>> | PAGE_SIZE | PMD | PUD | PMD | PUD |
>>>> -----------------------------|-----------------|
>>>> | 4K | 2M | 1G | 1M | 256M |
>>>> | 16K | 32M | 64G | 16M | 16G |
>>>> | 64K | 512M | 4T | 256M | 1T |
>>>> ------------------------------------------------
>>>>
>>>
>>> Interesting. That means user space will have it even harder to optimize
>>> for THP sizes.
>>>
>>> What's the effect on cont-pte? Do they still span the same number of
>>> entries and there is effectively no change?
>>
>> The numbers are the same for 4K base page size but will need
>> some changes for 16K and 64K base page sizes. Something that
>> git missed in this series, will fix it.
>
> Oh, and it would be great to also clearly spell out the effect on
> hugetlb as well. I assume the available hugetlb sizes will change as well.

Sure will update the required information in the commit message as well as in
file arch/arm64/mm/hugetlb.c, where HugeTLB sizes support matrix is enlisted.