On Thu, Sep 16, 2021 at 07:13:15PM -0400, Pasha Tatashin wrote:
> In case of kdump or when segments are already in place the relocation
> is not needed, therefore the setup of relocation function and call to
> it can be skipped.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> Suggested-by: James Morse <james.morse@xxxxxxx>
> ---
> arch/arm64/kernel/machine_kexec.c | 34 ++++++++++++++++++-----------
> arch/arm64/kernel/relocate_kernel.S | 3 ---
> 2 files changed, 21 insertions(+), 16 deletions(-)
[...]
> @@ -188,19 +190,25 @@ void machine_kexec(struct kimage *kimage)
> local_daif_mask();
>
> /*
> - * cpu_soft_restart will shutdown the MMU, disable data caches, then
> - * transfer control to the kern_reloc which contains a copy of
> - * the arm64_relocate_new_kernel routine. arm64_relocate_new_kernel
> - * uses physical addressing to relocate the new image to its final
> - * position and transfers control to the image entry point when the
> - * relocation is complete.
> + * Both restart and cpu_soft_restart will shutdown the MMU, disable data
> + * caches. However, restart will start new kernel or purgatory directly,
> + * cpu_soft_restart will transfer control to arm64_relocate_new_kernel
> * In kexec case, kimage->start points to purgatory assuming that
> * kernel entry and dtb address are embedded in purgatory by
> * userspace (kexec-tools).
> * In kexec_file case, the kernel starts directly without purgatory.
> */
> - cpu_soft_restart(kimage->arch.kern_reloc, kimage->head, kimage->start,
> - kimage->arch.dtb_mem);
> + if (kimage->head & IND_DONE) {
> + typeof(__cpu_soft_restart) *restart;
> +
> + cpu_install_idmap();
> + restart = (void *)__pa_symbol(function_nocfi(__cpu_soft_restart));
> + restart(is_hyp_nvhe(), kimage->start, kimage->arch.dtb_mem,
> + 0, 0);
Why can't you call:
cpu_soft_restart(kimage->start, kimage->arch.dtb_mem, 0, 0);
here instead of open-coding it?
Will
