On 03/25/19 at 01:01pm, Borislav Petkov wrote: > On Mon, Mar 25, 2019 at 10:36:33AM +0000, Junichi Nomura wrote: > > AFAIU, early parsing is new code in v5.1-rc1 to support kexec on systems > > with hotpluggable memory with KASLR enabled. For systems that requires the > > new feature, it may be ok to say "you need to use another kexec interface" > > and/or "you need new kexec-tools". > > No, this exactly should *not* happen. kexec is already full of duct tape > - don't need any more of that. > > So I suggested that efi_get_rsdp_addr() should exit early on in the > kexeced kernel but making this all play nice with the kexec-ed kernel, > as Dave suggests, is better. > > Now, my next question is: why does the RDSP address need to come from > kexec(1) (by way of efi_setup_data) and why can't the kexec'ed kernel > figure it out itself by parsing the EFI tables in a similar way to > efi_get_rsdp_addr ? efi_enter_virtual_mode() can only run once because of efi firmware/spec limitation, and after entered virtual mode, efi firmware just updated the original efi sys table, for example the original systab64->fw_vendor, systab64->tables, and even smbios (only found on some HPE machine) are changed from physcial address to virtual address. In the current efi_get_rsdp_addr, it assumes the efi config tables address is not touched (as physical addresses), it will break then. Kexec saved the original physical addresses, and pass them to kexeced kernel via x86 setup_data, so both the early parsing or efi init code need to get those physical values from setup_data. Thanks Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
