* Li Zhijian <lizhij...@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