On Thu, Apr 18, 2013 at 11:07:06PM +0100, Bryan O'Donoghue wrote: > > > UEFI stands for "Unified Extensible Firmware Interface", where "Firmware" > > is an ancient African word meaning "Why do something right when you can > > do it so wrong that children will weep and brave adults will cower before > > you", and "UEI" is Celtic for "We missed DOS so we burned it into your > > ROMs". The UEFI specification provides for runtime services (ie, another > > way for the operating system to be forced to depend on the firmware) and > > we rely on these for certain trivial tasks such as setting up the > > bootloader. But some hardware fails to work if we attempt to use these > > runtime services from physical mode, and so we have to switch into virtual > > mode. So far so dreadful. > > > > "UEI" is Celtic for "We missed DOS so we burned it into your ROMS" > > I love it "maith an fear" > > >There are currently only two situations where we need to map EFI Boot > >Service regions, > > > > 1. To workaround the firmware bug described in 916f676f8 > > 2. To access the ACPI BGRT image > > > >but since we haven't seen an i386 implementation that requires either, > >this simple fix should suffice for now. Item 2. above does still work on > >i386 provided that the BGRT image is not in highmem. > > Matt, Peter, Josh, Darren. > > Given it's not possible to guarantee someone won't stuff a BGRT into > EFI_BOOT_MEMORY >= highmem eventually (and indeed the axioms of the > universe pretty much guarantee eventually it will be so) - I'd > suggest version 2. > > A kernel parameter - rather than a probe for BGRT - since we > anticipate BIOS bugs on the way. > > Version 2 of the submitted path introduces an early kernel parameter > "virt_mapboot" - which is true by default (maintaining the current > behavior of mapping EFI_BOOT_MEMORY by default) - but which can be > set to false - if your IA32 BIOS is not buggy. > > Perhaps it would be better to be optimistic. > > Change the behavior of efi_enter_virtual_mode() to do the right > thing re: the standard and require passing of a parameter to switch > on work-arounds for non-standards conformant BIOS. Note: this > approach would break BGRT code - requiring addition of kernel > parameters to existing systems - which from a user-friendliness POV > is probably verboten.... I'd much rather see the code do the right thing automatically, rather than requiring an "unbreak me" command-line parameter. But in any case, since BGRT is a "make my system look prettier" feature rather than core functionality, giving up on it on 32-bit EFI seems fairly reasonable, especially since it may still work if stored sufficiently low in memory. - Josh Triplett -- 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
