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.
--
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
