* 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
