explain how exactly this efi_mem_reserve() causes trouble for the
kexec-ed kernel so that we can think of a proper solution, not some
random hackery.
The above details explain why and how efi_arch_mem_reserve() causes trouble for the (nested) kexec-ed kernel, additionally, there is a another reason to skip efi_arch_mem_reserve() altogether for the kexec case, as for kexec use case we need to use the EFI memmap passed from the 1st kernel via setup_data and probably need to avoid any additional EFI memory map additions/updates.
Therefore, the first revision of this patch had the following code to skip efi_arch_mem_reserve():
void __init efi_arch_mem_reserve(..) {
+ if (efi_setup) + return;
But then based on upstream review/feedback, the second revision of this patch, updated the patch to check the md attribute of the EFI memory descriptor instead of checking for efi_setup for detecting if running under kexec kernel and the checking of the md attribute of the EFI memory descriptor introduces these additional checks and pr_err() which you commented on above.
Hopefully, the above detailed explanation captures the reason to skip efi_arch_mem_reserve() in case of (SNP) guest kexec, looking forward to your comments/feedback on the same for me to rework this patch (especially the commit message) and post it again.