[PATCH] efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted

[Seth Forshee]

On Wed, Feb 20, 2019 at 03:51:34PM +0100, Paolo Pisati wrote:
> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> 
> The UEFI spec revision 2.7 errata A section 8.4 has the following to
> say about the virtual memory runtime services:
> 
>   "This section contains function definitions for the virtual memory
>   support that may be optionally used by an operating system at runtime.
>   If an operating system chooses to make EFI runtime service calls in a
>   virtual addressing mode instead of the flat physical mode, then the
>   operating system must use the services in this section to switch the
>   EFI runtime services from flat physical addressing to virtual
>   addressing."
> 
> So it is pretty clear that calling SetVirtualAddressMap() is entirely
> optional, and so there is no point in doing so unless it achieves
> anything useful for us.
> 
> This is not the case for 64-bit ARM. The identity mapping used by the
> firmware is arbitrarily converted into another permutation of userland
> addresses (i.e., bits [63:48] cleared), and the runtime code could easily
> deal with the original layout in exactly the same way as it deals with
> the converted layout. However, due to constraints related to page size
> differences if the OS is not running with 4k pages, and related to
> systems that may expose the individual sections of PE/COFF runtime
> modules as different memory regions, creating the virtual layout is a
> bit fiddly, and requires us to sort the memory map and reason about
> adjacent regions with identical memory types etc etc.
> 
> So the obvious fix is to stop calling SetVirtualAddressMap() altogether
> on arm64 systems. However, to avoid surprises, which are notoriously
> hard to diagnose when it comes to OS<->firmware interactions, let's
> start by making it an opt-out feature, and implement support for the
> 'efi=novamap' kernel command line parameter on ARM and arm64 systems.
> 
> ( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
>   used, given that the physical memory map and the kernel virtual address
>   map are not guaranteed to be non-overlapping like on arm64. However,
>   having support for efi=novamap,noruntime on 32-bit ARM, combined with
>   the recently proposed support for earlycon=efifb, is likely to be useful
>   to diagnose boot issues on such systems if they have no accessible serial
>   port. )
> 
> Tested-by: Jeffrey Hugo <jhugo at codeaurora.org>
> Tested-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> Tested-by: Lee Jones <lee.jones at linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: AKASHI Takahiro <takahiro.akashi at linaro.org>
> Cc: Alexander Graf <agraf at suse.de>
> Cc: Borislav Petkov <bp at alien8.de>
> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> Cc: Leif Lindholm <leif.lindholm at linaro.org>
> Cc: Linus Torvalds <torvalds at linux-foundation.org>
> Cc: Matt Fleming <matt at codeblueprint.co.uk>
> Cc: Peter Jones <pjones at redhat.com>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya at intel.com>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: linux-efi at vger.kernel.org
> Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.org
> Signed-off-by: Ingo Molnar <mingo at kernel.org>
> (cherry picked from commit 4e46c2a956215482418d7b315749fb1b6c6bc224)

This commit doesn't appear to be in Linus' tree. Where did it come from?