From: Lennart Poettering <lennart@poettering.net>
Date: Fri, 15 Nov 2024 08:38:38 +0000 (+0100)
Subject: boot: explain the 4G quirks we apply to initrd memory allocations
X-Git-Tag: v257-rc2~10
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9386bcc2da38508d07ecdb03bfbf354796b31a6b;p=thirdparty%2Fsystemd.git

boot: explain the 4G quirks we apply to initrd memory allocations

Given how long it took to come to a conclusion of the discussions around
https://github.com/systemd/systemd/issues/35026, let's add a comment
that makes this easier to grok for the next time this comes up.

Follow-up for: 6e207b370e91e681efb08c497a6c8ad78e3c8d83
---

diff --git a/src/boot/util.h b/src/boot/util.h
index 3164d520bd2..af14a0e31e4 100644
--- a/src/boot/util.h
+++ b/src/boot/util.h
@@ -100,6 +100,13 @@ static inline Pages xmalloc_pages(
 }
 
 static inline Pages xmalloc_initrd_pages(size_t n_pages) {
+        /* The original native x86 boot protocol of the Linux kernel was not 64bit safe, hence we allocate
+         * memory for the initrds below the 4G boundary on x86, since we don't know early enough which
+         * protocol we'll use to ultimately boot the kernel. This restriction is somewhat obsolete, since
+         * these days we generally prefer the kernel's newer EFI entrypoint instead, which has no such
+         * limitations. On other architectures we do not bother with any restriction on this, in particular
+         * as some of them don't even have RAM mapped to such low addresses. */
+
 #if defined(__i386__) || defined(__x86_64__)
         return xmalloc_pages(
                         AllocateMaxAddress,