tree fd1dfd4338d7c7d5bbdee555598a4c8c95ac0fd1
parent ec3e4dfeec22a2c78d6c7fbccf006bf4a7ba635d
author Andy Shevchenko <andriy.shevchenko@linux.intel.com> 1731512677 +0200
committer Simon Horman <horms@kernel.org> 1731663719 +0000

kexec: x86: Include pref_address when looking for a memory hole

When the kernel is built relocatable, the starting address can be
anything above 1Mb on x86. However, the startup_*() entries consider
that the minumum address for the kernel for the decompression has to
be at least LOAD_PHYSICAL_ADDR which is turn the value that is provided
as pref_address in boot protocol. The boot protocol itself says:

  This field, if nonzero, represents a preferred load address for the
  kernel.  A relocating bootloader should attempt to load at this
  address if possible.

Besides that the code in the kernel (arch/x86/kernel/kexec-bzimage64.c)
has these lines (in bzImage64_load() function):

    if (header->pref_address < MIN_KERNEL_LOAD_ADDR)
        kbuf.buf_min = MIN_KERNEL_LOAD_ADDR;
    else
        kbuf.buf_min = header->pref_address;

All that said, do the same in kexec tools. Without this patch
the relocatable kernel may end up in the memory hole that is
not enough for in-place decompression and Bad Things will happen
as it's proven on Intel Merrifield, that has a reserved memory
block starting at 64Mb.

Note, it doesn't mean that kernel has no issues itself in this particular
stage, but at least we may work around some corner cases for kexec.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Simon Horman <horms@kernel.org>