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?
--
Khalid
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
