On Thu, Jan 02, 2020 at 05:52:39PM +0100, Ard Biesheuvel wrote: > On Thu, 2 Jan 2020 at 17:45, Russ Anderson <rja@xxxxxxx> wrote: > > > > I want to make sure my undestanding of what you are proposing > > is the same as what you are proposing. > > > > What I am proposing is to document efi=old_map as only being available > on kernels built with CONFIG_X86_UV=y, and moving the code that > implements it into the UV support code. > > > I will have some additional background information shortly. > > > > Thanks, that is very helpful. After talking with some engineers, here is a brief history. When EFI new mapping was implemented, it did not work with the SGI UV1 bios, which worked with the old EFI mapping. Boris added the efi=old_map quirk as a workaround to keep UV1 working. SGI UV2 bios (and later) have a fix for that issue, so the quirk was modified for just UV1 by this commit. That allowed new EFI mapping to be used on newer UV platforms. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/platform/efi/quirks.c?id=d394f2d9d8e1e7b4959819344baf67b5995da9b0 There have been at least two other times efi=old_map has been used to work around issues. One was when KASLR was added (as part of the Spectre/Meldown mitigation). The initial implementation broke with new map so efi=old_map was used as a workaround. I don't know if this was a distro specific breakage or upstream, but the workaround limited the impact and the breakage was quickly fixed. Another time was the EFI locking issue mentioned earlier in this thread. Those are a couple of examples of efi=old_map being used after the UV1 platform. They were cases of issues that impacted the new EFI mapping, not platform or bios issues, and having the ability to fall back to the old EFI mapping helped minimize the impact. Neither were problems in the new EFI mapping code itself, with the new mapping an innocent victim of other issues. Having the efi=old_map quirk available with CONFIG_X86_UV=y makes it available on the platform I care about, and as it is enabled in the distros we support (SLES, RHEL, Oracle Linux) and Fedora. Not sure if anyone else has used efi=old_map to work around other issues, but this change would remove old_map as a possible workaround for others. Is there a compelling reason to put efi=old_map quirk under CONFIG_X86_UV=y? The original patch description assumed only old SGI UV1 used efi=old_map, that it had not been used on newer hardware, but that isn't the case. It has been used on newer currently shipping hardware. Given that new information is there a compelling reason for the change? Thanks. -- Russ Anderson, SuperDome Flex Linux Kernel Group Manager HPE - Hewlett Packard Enterprise (formerly SGI) rja@xxxxxxx
