[Question] Is there a reason to not support pagemaps level 5 ?

[linkdd]

PML5 is an Intel extension to increase addressable space from 256TB to 128PB (see wikipedia).

I admit it is a niche use case 🙂 But I was still wondering if there is any reason to not support it?

Since it uses bits from 48 to 57 for the new level, I guess it would break the safety checks for the VirtAddr type, are there other things that would break?

NB: The limine bootloader provides a way to detect if the CPU has the PML5 extension.

[Freax13]

AFAIK there is no reason we don't support 5-level paging, it's just that no one has implemented it yet. It might require redesigning some of the abstractions to support both 4-level and 5-level paging. Feel free to come up with ideas.

Since it uses bits from 48 to 57 for the new level, I guess it would break the safety checks for the VirtAddr type, are there other things that would break?

This would also break/require redesign of the page table related abstraction including Mapper and its implementations.

[phil-opp]

For VirtAddr, we could add a new generic parameter that allows specifying 4-level or 5-level paging. If we default to 4-level paging, we might be even able to avoid a breaking change. Maybe it's also possible to something similar for OffsetPageTable, etc.

[sarahspberrypi]

I noticed that the bitmask of the addr() function of PageTableEntry (see here) already supports 5-level paging (with 52 Bits) but the VirtAddr::new() function still only expects a 4-level address which is 47 bits long. This broke in my code when using SEV due to the C-Bit-Position being at either bit 47 (for older devices) or at bit 51 (for never AMD CPUs). I think we should adapt VirtAddr to allow bits 47-51 to be non-machting as well. Side note: If we align the bitmasks here with VirtAddrs requirements, we can safely use VirtAddr::new_unchecked() at this location.

[Freax13]

I noticed that the bitmask of the addr() function of PageTableEntry (see here) already supports 5-level paging (with 52 Bits) but the VirtAddr::new() function still only expects a 4-level address which is 47 bits long. This broke in my code when using SEV due to the C-Bit-Position being at either bit 47 (for older devices) or at bit 51 (for never AMD CPUs). I think we should adapt VirtAddr to allow bits 47-51 to be non-machting as well. Side note: If we align the bitmasks here with VirtAddrs requirements, we can safely use VirtAddr::new_unchecked() at this location.

(This misunderstands a few concepts/our APIs, there's been some discussion on this in #511).

[Freax13]

For VirtAddr, we could add a new generic parameter that allows specifying 4-level or 5-level paging. If we default to 4-level paging, we might be even able to avoid a breaking change. Maybe it's also possible to something similar for OffsetPageTable, etc.

Unfortunately, I don't think this can work without a breaking change because Rust doesn't allow specifying a default for generic parameters in functions.