On Fri, 3 Jan 2020 at 00:13, Russ Anderson <rja@xxxxxxx> wrote: > > 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. > So are you saying the distros updated their kernels which subsequently broke your platforms, and you needed to use efi=old_map in production to work around this? This sounds like something that should have been caught in testing before the release was made. Is there any way you could make one of these systems available/accessible for testing new kernels? Also, was the breakage related specifically to the use of the UV runtime services? > 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. > Indeed. > 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? > Every feature like this doubles the size of the validation matrix, and so restricting efi=old_map to a single target helps to keep the maintenance effort manageable.
