On 09/07/2012 01:57 AM, Khalid Aziz wrote: > On 09/05/2012 09:18 PM, Dave Young wrote: >> >>> I think running a kexec/kdump kernel with "noefi" is not a good idea. >>> Today kernel makes very little use of UEFI run time services but this >>> might change shortly. I have already seen ideas being proposed to use >>> UEFI variables to store kernel panic information which would require >>> accessing UEFI runtime services. If the kdump kernel runs into a panic, >>> it would be good to be able to use UEFI variables to store some sort of >>> tombstone. We might also start using UEFI runtime clock services one of >>> these days especially now that all PCs soon will have UEFI due to >>> Windows 8 requirements. There might be other ways to deal with EFI >>> virtualization issue. I have solved it on a custom ia64 kernel by >>> passing the kexec'd kernel a "kexec_reboot" on command line, although I >>> wouldn't recommend that approach as a general approach. Creating a new >>> kernel command line parameter just to tell the kernel to not virtualize >>> EFI sounds excessive. May be we can come up with a different way to tell >>> a kexec/kdump kernel to not virtualize EFI, like create a new signature, >>> for example "EL32_KEXEC" and "EL64_KEXEC", for >>> boot_params.efi_info.efi_loader_signature which tells the kexec/kdump >>> kernel to enable EFI but skip the step of virtualizing it. More work >>> will be needed to make this work, for example pass the EFI runtime >>> service memory map from one kernel to the next so we keep it mapped in >>> exact same spot, and other similar mapping issues. >>> >> >> I'm not so familiar with uefi detail, is the virtualization issue mean >> "virtual mode" of efi? From my understanding for kdump kernel I would >> vote for not interacting with bios at all. We have use "noefi" for long >> time by passing it to 2nd kernel while kexecing. I prefer to do this way >> until we have to switch to other approach. >> > Yes, that is what I mean by virtualizing issue. Using "noefi" for kdump > kernel will keep it from using any runtime EFI services. That could mean > kdump kernel may not be able to read clock or use EFI variables to store > a tombstone in case it runs into trouble. Is that acceptable? > > For the kexec'd kernel (not kdump kernel), being able to use runtime EFI > services will be essential as we move to EFI machines. We will have to > support enabling EFI on a kexec'd kernel. Does that sound reasonable? > It's probably needed, but currently relevant implementation is not ready especially efi init code for kdump. We can address this once it's ok. I did some digging about the efi boot kdump in slackware with kernel from latest linus tree. I'm surprise that kdump works even without these "noefi" and "acpi_rsdp=" With fedora 17 3.4.3 kernel passing "acpi_rsdp=" is enough for kdump kernel booting. Actually in x86 setup code if bootloader do not pass correct efi_info in boot_params efi_enabled will be set to 0 automaticlly. So as for this patch 'noefi' is not needed. I will do more testing to see why linus tree works without "acpi_rsdp=" -- Thanks Dave
