Hello,

 

Reposting from RFC mailing list since the mailing list for RFCs doesn't seem to be too active these days and my message there is stuck in moderator approval for multiple days.

 

This has been something that I was contemplating posting an email about for many months at this point but due to the rather large scope nature of the problem, I've been hesitant to bring it up. However, now that I'm further along in firmware bringup for Apple ARM platforms (unofficial Project Mu port to clarify, a hobby thing I'm mainly doing in free time, not associated with Apple at all), I feel it's important I bring this topic up now especially with how the ARM spec allows implementers to support page granules, and the potential for future systems to also have the same characteristics.

 

In short, EDK2 since the beginning has only ever supported 4K page allocations for all architectures and platforms it's been supported on. However, with the introduction of the M1 and Apple's ARM powered Macs (really since the Apple A9 launched in 2015, but the M1 and the ARM Macs are the first Apple platforms that Apple deliberately lets users run their own boot firmware on so I'm mostly scoping discussion to ARM Macs and such) it's clear that while Apple does support 4K pages (for Rosetta support), it's clear that these systems are 16K page granule systems first and foremost (a number of the IOMMUs on these systems *only* support 16k granule allocations, and XNU basically only uses 16K allocations for non-Rosetta processes) - and with the announcements that Rosetta and such are on the way out in the next year or two it's safe to assume that future Apple SoCs will *only* support 16k (and possibly 64k) page granules. This is already a problem for firmware bringup in my case for Apple ARM Macs because some IOMMUs *rely* on 16K page allocations to even work correctly and I can't properly add support for them at the moment without some ugly hacks. This issue isn't limited to Apple systems and SoCs though, as ARM leaves it implementation defined whether an ARM implementation supports 4k pages or not - and there could very well be systems in the future that do not implement 4K paging.

 

As a result of all of these factors, I'd like to get some input on what it would take to add proper support for 16k and 64k page granules and allocations in EDK2 for AARCH64 platforms that do not implement 4K paging. Since a lot of EDK2 is basically designed around 4K page granules, I imagine there would be a lot of work that would have to be done across a lot of modules to remove assumptions about 4K pages, but since the ARM spec states that systems can decide not to implement 4K page granules and translation, I don't think it's a topic that should be ignored too much longer. (Especially considering that the Linux kernel also supports full 16K only builds due to the push for ARM Mac support and Android is also going in that direction as well). Happy to write the patch myself as well or even just parts of it, right now I would appreciate some input into how difficult it would be to add support for different page granules without breaking everything in EDK2 since it seems like this would be a VERY breaking change just based on the source code comments in the files that implement page allocations.