From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id D3E787803D0 for ; Thu, 3 Jul 2025 23:37:56 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=1m65FQzbI0uqMcCMyk/nqg4hweEPHqPAVVNxjVptJow=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=groups1; t=1751585875; v=1; x=1751845075; b=NvS8SYTElO/OeSkMBlLCzTgMcfGsRixptXTjAgLuBK//4lFqZAA2ozcWVlELps1pLGgTLplj iz8W/Enu7Gze5pkbyjKPEqofI7m4RjN6EUvTe6wvLTegXXT0m2rLL4E5sGZyen+rR1gGfU5vT8b Y+f+ctEOPSNnIow1WF+ILpzcgrb4+4FoQToUngMf5gLPZb8rkwW5I2LJ+OJ/06vZmg7hx+Mr3/G O4ZvrIGQyIxCaBr5L/vvY8RVgBaB8g7LvoAPk09J5Za7O4GEgb/7iGf7Hbn5bnoEhaVFxirkFqq 6+RZ3yrsvkr6c/fVLIplrdqmtM0AVWF+6SONWwlaIoLzA== X-Received: by 127.0.0.2 with SMTP id qnDGYY7687511x8PXZKD1ogY; Thu, 03 Jul 2025 16:37:55 -0700 Subject: [edk2-devel] [Discussion] Want some input on potentially adding support for 16K and 64K page granules and allocations in AARCH64 EDK2 (for systems that do not support 4K paging modes) To: devel@edk2.groups.io From: "Arminder Singh via groups.io" X-Originating-Location: East Brunswick, New Jersey, US (73.33.181.76) X-Originating-Platform: Mac Safari 18.3 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 03 Jul 2025 16:37:54 -0700 Message-ID: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,arminders208@outlook.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: GKvYn4aEJ9s2bEWohxUiVafdx7686176AA= Content-Type: multipart/alternative; boundary="RRGMssoc5Ey0miJPWvkI" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=groups1 header.b=NvS8SYTE; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --RRGMssoc5Ey0miJPWvkI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Reposting from RFC mailing list since the mailing list for RFCs doesn't see= m to be too active these days and my message there is stuck in moderator ap= proval 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 a= long in firmware bringup for Apple ARM platforms (unofficial Project Mu por= t to clarify, a hobby thing I'm mainly doing in free time, not associated w= ith Apple at all), I feel it's important I bring this topic up now especial= ly 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 allocati= ons for all architectures and platforms it's been supported on. However, wi= th the introduction of the M1 and Apple's ARM powered Macs (really since th= e Apple A9 launched in 2015, but the M1 and the ARM Macs are the first Appl= e 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 w= hile Apple does support 4K pages (for Rosetta support), it's clear that the= se systems are 16K page granule systems first and foremost (a number of the= IOMMUs on these systems *only* support 16k granule allocations, and XNU ba= sically 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 (an= d possibly 64k) page granules. This is already a problem for firmware bring= up in my case for Apple ARM Macs because some IOMMUs *rely* on 16K page all= ocations to even work correctly and I can't properly add support for them a= t the moment without some ugly hacks. This issue isn't limited to Apple sys= tems and SoCs though, as ARM leaves it implementation defined whether an AR= M implementation supports 4k pages or not - and there could very well be sy= stems 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 allocati= ons 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 t= o remove assumptions about 4K pages, but since the ARM spec states that sys= tems 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 cons= idering 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 we= ll). Happy to write the patch myself as well or even just parts of it, righ= t now I would appreciate some input into how difficult it would be to add s= upport for different page granules without breaking everything in EDK2 sinc= e it seems like this would be a VERY breaking change just based on the sour= ce code comments in the files that implement page allocations. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121455): https://edk2.groups.io/g/devel/message/121455 Mute This Topic: https://groups.io/mt/113976011/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --RRGMssoc5Ey0miJPWvkI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
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 moderat= or approval for multiple days.
 
This has been something that I was contemplating posting an email abou= t 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 furt= her along in firmware bringup for Apple ARM platforms (unofficial Project M= u port to clarify, a hobby thing I'm mainly doing in free time, not associa= ted with Apple at all), I feel it's important I bring this topic up now esp= ecially 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 all= ocations for all architectures and platforms it's been supported on. Howeve= r, with the introduction of the M1 and Apple's ARM powered Macs (really sin= ce 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 firm= ware on so I'm mostly scoping discussion to ARM Macs and such) it's clear t= hat while Apple does support 4K pages (for Rosetta support), it's clear tha= t these systems are 16K page granule systems first and foremost (a number o= f the IOMMUs on these systems *only* support 16k granule allocations, and X= NU basically only uses 16K allocations for non-Rosetta processes) - and wit= h the announcements that Rosetta and such are on the way out in the next ye= ar or two it's safe to assume that future Apple SoCs will *only* support 16= k (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 pag= e allocations to even work correctly and I can't properly add support for t= hem at the moment without some ugly hacks. This issue isn't limited to Appl= e 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 wha= t it would take to add proper support for 16k and 64k page granules and all= ocations in EDK2 for AARCH64 platforms that do not implement 4K paging. Sin= ce a lot of EDK2 is basically designed around 4K page granules, I imagine t= here would be a lot of work that would have to be done across a lot of modu= les to remove assumptions about 4K pages, but since the ARM spec states tha= t systems can decide not to implement 4K page granules and translation, I d= on'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 t= o 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.
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#121455) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--RRGMssoc5Ey0miJPWvkI--