On Mon, 3 Jun 2024 at 23:33, Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > On Mon, Jun 03, 2024 at 04:46:39PM +0200, Borislav Petkov wrote: > > On Mon, Jun 03, 2024 at 09:01:49AM -0500, Kalra, Ashish wrote: > > > If we skip efi_arch_mem_reserve() (which should probably be anyway skipped > > > for kexec case), then for kexec boot, EFI memmap is memremapped in the same > > > virtual address as the first kernel and not the allocated memblock address. > > > > Are you saying that we should simply do > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > index fdf07dd6f459..410cb0743289 100644 > > --- a/drivers/firmware/efi/efi.c > > +++ b/drivers/firmware/efi/efi.c > > @@ -577,6 +577,9 @@ void __init efi_mem_reserve(phys_addr_t addr, u64 size) > > if (WARN_ON_ONCE(efi_enabled(EFI_PARAVIRT))) > > return; > > > > + if (kexec_in_progress) > > + return; > > + kexec_in_progress is only for checking if this is in a reboot (kexec) code path. But eif_mem_reserve is only called during the boot time so checking kexec_in_progress is meaningless here. current_kernel_is_booted_via_kexec != is_rebooting_with_kexec The code change below in the patch looks good to me, but I'm not sure what caused the memory corruption, it indeed worth some more digging, maybe SEV/SNP related. + if (md.attribute & EFI_MEMORY_RUNTIME) + return; Thanks Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
