Re: kexec's v1 compatibility code

[David Vrabel <dvrabel@cantab.net>]

On 08/05/15 14:34, Jan Beulich wrote:
> David,
> 
> now that we're putting Xen 4.4.x underneath an older distro (SLE11)
> we've got to see that kexec doesn't work there. Initial investigation
> of our kexec person revealed that the destinations attempted to be
> written to by kexec_reloc()'s code following the is_source and
> is_zero labels have no mappings in the kexec page tables. Comparing
> kexec_do_load_v1() with kexec_load() I wonder whether the former
> isn't simply lacking a call to kimage_load_segments().

I think I only tested the V1 path with 32-bit images which did not need
page tables.

The caller of the V1 kexec_load has already loaded the segments into
their (potentially intermediate) destination so the apparently missing
kimage_load_segments() is deliberate.

I think kimage_build_ind() needs to call machine_kexec_add_page()
appropriately.

> He worked around this (I haven't seen the code yet that he used)
> to then find that the dump kernel (other than an "ordinary" kexec
> one) also expects at least the low 640k to be mapped. He's
> suggesting that Linux'es kexec code sets up an identity mapping of
> all memory, and that we should do the same. I can't say I'm
> convinced of this though, as it seems bogus to me that the dump
> kernel should depend on anything beyond a bare minimum
> environment it is being handed control in; I would instead expect
> the crash kernel to be responsible for any such specific needs.

The version of kexec-tools that works with the V2 ABI, adds an extra
segment (with no source buffer) to add a mapping of 0-1MIB that
purgatory expects.  Perhaps the v1 compat code needs to do the same?

> May I also ask whether that compatibility code got tested?

Only with 32-bit images -- hence the page table related problems.

David