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

[Seth Forshee]

On Fri, Feb 22, 2019 at 11:29:19AM +0100, Paolo Pisati wrote:
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c2a956215482418d7b315749fb1b6c6bc224

Ok, in the future you should include that information like this:

(cherry picked from commit 4e46c2a956215482418d7b315749fb1b6c6bc224
 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)

Otherwise it is assumed the sha1 is from Linus' tree.

> 
> On Fri, Feb 22, 2019 at 11:09 AM Seth Forshee
> <seth.forshee at canonical.com> wrote:
> >
> > 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?
> >
> 
> 
> -- 
> bye,
> p.