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 0A360940FDB for ; Fri, 4 Jul 2025 06:29:28 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=SRMG/VQUfeOXufQxPTtsK2N/4vEu3fmym6XY0Na8edY=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=groups1; t=1751610567; v=1; x=1751869767; b=c9GVzz0o86eiNzlkMUqH0GE3PoJASNHsG5vV3N+Z2Q38V5fLfRfJnhVaII/l1tdF/BYYV8+C Q0LnqszOi8Os3NR4LP19HFVbI50h4NNuET+X4snMrPggThTZpZbi0TXrlm9buc3JOsyFxZVCE5H ChuA5OzPURZGnORYVpiP0jIHB4+EuN2/ybcUy+6ejeeFfJRdXCwrzU+SNKru4hVLQWCmUfRJ4Fu gLcbsdJ8diIgwUIuYU3vgwZMoLZ4V113p/knLvDiEI1tbNujpdgcyxGHQS8MxaDLh5P0ZGQtv/g g7O3l3v88DTFkour0nYVKhf0Y7HrN9YgZUrBsuvZliDQA== X-Received: by 127.0.0.2 with SMTP id dbs3YY7687511xPlKQ5J02RW; Thu, 03 Jul 2025 23:29:27 -0700 X-Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by mx.groups.io with SMTP id smtpd.web10.6756.1751610566663345377 for ; Thu, 03 Jul 2025 23:29:26 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D2E6AA5371F for ; Fri, 4 Jul 2025 06:29:25 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83FD4C4CEEF for ; Fri, 4 Jul 2025 06:29:25 +0000 (UTC) X-Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-32b561a861fso5294211fa.0 for ; Thu, 03 Jul 2025 23:29:25 -0700 (PDT) X-Gm-Message-State: fMgwhJe6V5nq5sAx7cLl2V41x7686176AA= X-Google-Smtp-Source: AGHT+IFyPTYhCkF7BfuswZUfVGI+U2B+A5KnwT9d5SQ/CnZF0LxJQIB4Ff45HUL11MhhG6lenqZSo7V1rBeLWt9z9mc= X-Received: by 2002:a2e:bc0c:0:b0:32b:3b5a:c4a2 with SMTP id 38308e7fff4ca-32e5f55bbc0mr3698221fa.6.1751610563864; Thu, 03 Jul 2025 23:29:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel via groups.io" Date: Fri, 4 Jul 2025 08:29:12 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXxZD5P8iwY0pl9-XzlR4-kiyewSy9WBZ0ZWPGgIdNUIprpAZd8--CY54rg Message-ID: Subject: Re: [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, arminders208@outlook.com, Leif Lindholm 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 Resent-Date: Thu, 03 Jul 2025 23:29:26 -0700 Resent-From: ardb@kernel.org Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=groups1 header.b=c9GVzz0o; 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 Proper support would entail changing the UEFI spec and this is not going to= fly. However, given that all memory is mapped 1:1 under UEFI, the problem is rather limited in scope. Allocations can still be performed in 4k granules, the only problem is the use of restricted permissions on code and data regions, where a single 16k mapping covers both. - For system firmware, this can be worked around by building the components with 16k segment alignment, so that code and data never share a 16k page. - For third party apps and drivers, it would require some special handling in the system firmware to avoid restricted mappings on regions that need both executable and writable permissions. I did the experiment about 8 years ago for 64k pages, and with minor surgery, EDK2 executed fine. I think it does make sense for guidance to be added to the UEFI spec that on AARCH64, PE/COFF images should prefer 64k section alignment if interoperability with these systems is a potential concern. On Fri, 4 Jul 2025 at 01:37, Arminder Singh via groups.io wrote: > > Hello, > > Reposting from RFC mailing list since the mailing list for RFCs doesn't s= eem 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 f= or many months at this point but due to the rather large scope nature of th= e 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 p= ort 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 especi= ally with how the ARM spec allows implementers to support page granules, an= d the potential for future systems to also have the same characteristics. > > In short, EDK2 since the beginning has only ever supported 4K page alloca= tions 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 Ap= ple platforms that Apple deliberately lets users run their own boot firmwar= e 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 t= hese systems are 16K page granule systems first and foremost (a number of t= he IOMMUs on these systems *only* support 16k granule allocations, and XNU = basically only uses 16K allocations for non-Rosetta processes) - and with t= he 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 bri= ngup in my case for Apple ARM Macs because some IOMMUs *rely* on 16K page a= llocations 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 s= ystems 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 i= t would take to add proper support for 16k and 64k page granules and alloca= tions 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 ther= e 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 s= ystems 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 co= nsidering that the Linux kernel also supports full 16K only builds due to t= he 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, ri= ght now I would appreciate some input into how difficult it would be to add= support for different page granules without breaking everything in EDK2 si= nce it seems like this would be a VERY breaking change just based on the so= urce 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 (#121456): https://edk2.groups.io/g/devel/message/121456 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-