Messages in this thread | | | Date | Fri, 9 Nov 2018 08:20:15 +0100 | From | Ingo Molnar <> | Subject | Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd |
| |
* Li Zhijian <lizhijian@cn.fujitsu.com> wrote:
> > If the kernel initrd creation process creates an initrd which > > is larger than 2GB and also claims that it can't be placed > > with any part of it above 2GB, then that sounds like a bug > > in the initrd creation process... > > Exactly, it's a real problem. > > Add x86 maintainers and LKML: > > The background is that QEMU want to support up to 4G initrd. but linux header ( > initrd_addr_max field) only allow 2G-1. > Is one of the below approaches reasonable: > 1) change initrd_addr_max to 4G-1 directly simply(arch/x86/boot/header.S)? > 2) lie QEMU bootloader the initrd_addr_max is 4G-1 even though header said 2G-1 > 3) any else
A 10 years old comment from hpa says:
initrd_addr_max: .long 0x7fffffff # (Header version 0x0203 or later) # The highest safe address for # the contents of an initrd # The current kernel allows up to 4 GB, # but leave it at 2 GB to avoid # possible bootloader bugs.
To avoid the potential of bugs lurking in dozens of major and hundreds of minor iterations of various Linux bootloaders I'd prefer a real solution and extend it - because if there's a 2GB initrd for some weird reason today there might be a 4GB one in two years.
The real solution would be to:
- Extend the boot protocol with a 64-bit field, named initrd_addr64_max or such.
- We don't change the old field - but if the new field is set by new kernels then new bootloaders can use that as a new initrd_addr64_max value. (or reject to load the kernel if the address is too high.)
- The kernel build should also emit a warning when building larger than 2GB initrds, with a list of bootloaders that support the new protocol.
Or something along those lines.
Thanks,
Ingo
| |