Re: [PATCH] Remove warning in efi_enter_virtual_mode V2

[Bryan O'Donoghue <bryan.odonoghue.lkml-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>]

On 19/04/13 06:58, Greg KH wrote:
>> This patch gives the option to switch off that behavior - if your BIOS
>> has neither BGRT - nor bugs that require mapping of EFI boot code/data
>
> No, never add new boot options, no users, or distros, know to set them.
> Isn't there some way we can dynamically determine this instead?

Peter, Greg.

There are three issues to consider here

1: Some UEFI BIOS is buggy and the EFI_RUNTIME_SERVICES code - actually 
touches EFI_BOOT_MEMORY. Boot memory should be completely untouched 
after an entity calls ExitBootServices() - typically done by an EFI 
aware bootloader before handing off to Linux.

2: Existing code maps EFI_BOOT_MEMORY in arch/x86/platform/efi/efi.c.
Initially it looked to me as though you could probe for ACPI::BGRT - 
look for an ACPI object sometimes stored in EFI_BOOT_MEMORY and use that 
to determine if EFI_BOOT_MEMORY should be mapped. I wasn't aware #1 
above was also a concern. So just probing for something - doesn't appear 
to fly

3: Standards compliant EFI BIOS - like the reference EFI 2.3.1 code we 
have on my project, has neither of the two above problems to work around

So we can.

1. Just silently map EFI_BOOT_MEMORY - even on unbuggy platforms like #3 
- or we can

2. Introduce some sort of intelligence - a parameter somewhere to tell 
the efi_enter_virtual mode if/when to map EFI_BOOT_MEMORY.

3. Just go the suggested route from Josh
#ifdef CONFIG_X86_64
			if (md->type != EFI_BOOT_SERVICES_CODE &&
			    md->type != EFI_BOOT_SERVICES_DATA)
#endif

Option #3 - so long as it doesn't break ia32::BGRT systems works for me.