On Wed, 06 Aug, at 02:06:23PM, Leif Lindholm wrote: > On Wed, Aug 06, 2014 at 04:38:25PM +0800, Dave Young wrote: > > > > Adding a noefi boot param like in X86 to disable efi runtime services support. > > > > This will be useful for debugging uefi problems. Also it will be useful > > for later kexec/kdump work. Kexec on uefi support in X86 depends on a fixed vm > > area specific for uefi runtime 1:1 mapping, kernel will switch to a different > > page table for any uefi runtime callback in virtual mode. In arm64 similar > > work probably is necessary. But kexec boot will just works with 'noefi' with > > the limitaion of lacking runtime services. The runtime services is not critical > > for kdump kernel for now. So as for kexec/kdump just leave the 1:1 mapping a > > future work. > > Since this is really turning an x86-specific feature into a generic > one, could it be moved to core code? > Maybe an efi.mask, reusing the efi_enabled defines, with an > efi_disabled macro? Why the new efi_disabled() and efi.mask? This is all achievable with efi_enabled() and efi.flags, in fact, this kind of thing is exactly why they were invented. > Also, since this patch (and its x86 predecessor) is not really > "noefi", could this be integrated with the "efi=" patch > (http://permalink.gmane.org/gmane.linux.kernel.efi/4405), > as an efi=noruntime option? > > On x86, due to CSM, "noefi" was a useful fallback for completely > broken (U)EFI implementations - but on an arm* UEFI system, there will > be no fallback. Could it be wrapped in a kernel hacking config option? I don't mind making "noefi" a synonym for "efi=noruntime" on x86, as long as we keep "noefi" around with the same semantics it's always had. And certainly if you're coming at this anew (like on arm(64)), I agree "efi=noruntime" just makes a ton more sense than "noefi". -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
