kexec and relocatable kernels
H. Peter Anvin
hpa at zytor.com
Tue Jan 11 11:22:12 EST 2011
On 01/11/2011 04:06 AM, Neil Horman wrote:
> Not sure I completely follow here. Clearly kdump uses relocatable kernels, and
> so can avoid this problem. But what part of the reboot path affects relocation
> such that if your not using kdump, you wind up relocating into a memory hole.
> As I understood it (and I admittedly haven't gone back to look as I write this),
> the relocation code lives in the header of the kernel image, so it should be the
> same weather we're booting on panic (via kdump), or just booting a new kernel
> (via kexec -e). Is something getting messed up in the header data that kexec
> doesn't inform the kernel of the presence of a memory hole in some cases?
No, the problem is that kexec doesn't check if the placement of the
kernel will interfere with a memory hole when picking a default load
location; it always load a replacement (as opposed to kdump) kernel at
0x100000. For at least a >= 2.10 kernel, it can do better: check to see
if the actual placement will interfere with the memory map and if so,
place it differently.
More information about the kexec