From 9386bcc2da38508d07ecdb03bfbf354796b31a6b Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Fri, 15 Nov 2024 09:38:38 +0100 Subject: [PATCH] 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 --- src/boot/util.h | 7 +++++++ 1 file changed, 7 insertions(+) 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, -- 2.47.3