Re: kexec's v1 compatibility code

[Andrew Cooper <andrew.cooper3@citrix.com>]

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().
>
> 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.
>
> May I also ask whether that compatibility code got tested?

This is all from a while ago.  It is quite possible that we didn't
actually tested the compatibility case with a 64bit dom0 kernel,
although I certainly did test earlier versions of the series with a
32bit dom0 kernel.  The work was done long before XenServer moved to a
64bit dom0, and was done by deleting everything and starting from scratch.

IIRC, the low 640k mappings is a purgatory bug rather than Linux, and
has been fixed upstream in kexec-tools since.  (I recall that it used to
take a backup copy of the IVT for some reason)

~Andrew