kexec and relocatable kernels

[Neil Horman]

On Tue, Jan 11, 2011 at 08:22:12AM -0800, H. Peter Anvin wrote:
> 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.
> 
> 	-hpa

Gotcha, so this is a kexec utility issue then, rather than a kernel problem, in
that kexec fills out the bzimage header without taking memory holes into account
ok, that makes more sense.  Thanks!
Neil