Hi Pavel,
On 26/03/2020 03:24, Pavel Tatashin wrote:
> Currently, kernel relocation function is configured in machine_kexec()
> at the time of kexec reboot by using control_code_page.
>
> This operation, however, is more logical to be done during kexec_load,
> and thus remove from reboot time. Move, setup of this function to
> newly added machine_kexec_post_load().
This would avoid the need to special-case the cache maintenance, so its a good cleanup...
> Because once MMU is enabled, kexec control page will contain more than
> relocation kernel, but also vector table, add pointer to the actual
> function within this page arch.kern_reloc. Currently, it equals to the
> beginning of page, we will add offsets later, when vector table is
> added.
If the vector table always comes second, wouldn't this be extra work to hold the value 0?
You can control the layout of this relocation code, as it has to be written in assembly.
I don't get why this would be necessary.
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index ae1bad0156cd..ec71a153cc2d 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -58,6 +59,17 @@ void machine_kexec_cleanup(struct kimage *kimage)
> /* Empty routine needed to avoid build errors. */
> }
>
> +int machine_kexec_post_load(struct kimage *kimage)
> +{
> + void *reloc_code = page_to_virt(kimage->control_code_page);
> +
> + memcpy(reloc_code, arm64_relocate_new_kernel,
> + arm64_relocate_new_kernel_size);
> + kimage->arch.kern_reloc = __pa(reloc_code);
Could we move the two cache maintenance calls for this area in here too. Keeping it next
to the modification makes it clearer why it is required.
In this case we can use flush_icache_range() instead of its __variant because this now
happens much earlier.
> + return 0;
> +}
Regardless,
Reviewed-by: James Morse <james.morse@xxxxxxx>
Thanks,
James
