linux-toradex.git/include/linux/efi.h, branch v4.9-rc5

Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into efi/core

2016-09-13T18:21:55+00:00

Pull EFI updates from Matt Fleming:

"* Refactor the EFI memory map code into architecture neutral files
   and allow drivers to permanently reserve EFI boot services regions
   on x86, as well as ARM/arm64 - Matt Fleming

 * Add ARM support for the EFI esrt driver - Ard Biesheuvel

 * Make the EFI runtime services and efivar API interruptible by
   swapping spinlocks for semaphores - Sylvain Chouleur

 * Provide the EFI identity mapping for kexec which allows kexec to
   work on SGI/UV platforms with requiring the "noefi" kernel command
   line parameter - Alex Thorlton

 * Add debugfs node to dump EFI page tables on arm64 - Ard Biesheuvel

 * Merge the EFI test driver being carried out of tree until now in
   the FWTS project - Ivan Hu

 * Expand the list of flags for classifying EFI regions as "RAM" on
   arm64 so we align with the UEFI spec - Ard Biesheuvel

 * Optimise out the EFI mixed mode if it's unsupported (CONFIG_X86_32)
   or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot
   services function table for direct calls, alleviating us from
   having to maintain the custom function table - Lukas Wunner

 * Miscellaneous cleanups and fixes"

Signed-off-by: Ingo Molnar

efi: Replace runtime services spinlock with semaphore

2016-09-09T15:08:43+00:00

The purpose of the efi_runtime_lock is to prevent concurrent calls into
the firmware. There is no need to use spinlocks here, as long as we ensure
that runtime service invocations from an atomic context (i.e., EFI pstore)
cannot block.

So use a semaphore instead, and use down_trylock() in the nonblocking case.
We don't use a mutex here because the mutex_trylock() function must not
be called from interrupt context, whereas the down_trylock() can.

Signed-off-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Mark Rutland 
Cc: Sylvain Chouleur 
Signed-off-by: Matt Fleming

efi: Don't use spinlocks for efi vars

2016-09-09T15:08:42+00:00

All efivars operations are protected by a spinlock which prevents
interruptions and preemption. This is too restricted, we just need a
lock preventing concurrency.
The idea is to use a semaphore of count 1 and to have two ways of
locking, depending on the context:
- In interrupt context, we call down_trylock(), if it fails we return
  an error
- In normal context, we call down_interruptible()

We don't use a mutex here because the mutex_trylock() function must not
be called from interrupt context, whereas the down_trylock() can.

Signed-off-by: Sylvain Chouleur 
Signed-off-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Mark Rutland 
Cc: Sylvain Chouleur 
Signed-off-by: Matt Fleming

efi: Use a file local lock for efivars

2016-09-09T15:08:41+00:00

This patch replaces the spinlock in the efivars struct with a single lock
for the whole vars.c file.  The goal of this lock is to protect concurrent
calls to efi variable services, registering and unregistering. This allows
us to register new efivars operations without having in-progress call.

Signed-off-by: Sylvain Chouleur 
Signed-off-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Mark Rutland 
Cc: Sylvain Chouleur 
Signed-off-by: Matt Fleming

efi/runtime-map: Use efi.memmap directly instead of a copy

2016-09-09T15:08:36+00:00

Now that efi.memmap is available all of the time there's no need to
allocate and build a separate copy of the EFI memory map.

Furthermore, efi.memmap contains boot services regions but only those
regions that have been reserved via efi_mem_reserve(). Using
efi.memmap allows us to pass boot services across kexec reboot so that
the ESRT and BGRT drivers will now work.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Signed-off-by: Matt Fleming

efi: Allow drivers to reserve boot services forever

2016-09-09T15:08:34+00:00

Today, it is not possible for drivers to reserve EFI boot services for
access after efi_free_boot_services() has been called on x86. For
ARM/arm64 it can be done simply by calling memblock_reserve().

Having this ability for all three architectures is desirable for a
couple of reasons,

  1) It saves drivers copying data out of those regions
  2) kexec reboot can now make use of things like ESRT

Instead of using the standard memblock_reserve() which is insufficient
to reserve the region on x86 (see efi_reserve_boot_services()), a new
API is introduced in this patch; efi_mem_reserve().

efi.memmap now always represents which EFI memory regions are
available. On x86 the EFI boot services regions that have not been
reserved via efi_mem_reserve() will be removed from efi.memmap during
efi_free_boot_services().

This has implications for kexec, since it is not possible for a newly
kexec'd kernel to access the same boot services regions that the
initial boot kernel had access to unless they are reserved by every
kexec kernel in the chain.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Signed-off-by: Matt Fleming

efi: Add efi_memmap_install() for installing new EFI memory maps

2016-09-09T15:07:47+00:00

While efi_memmap_init_{early,late}() exist for architecture code to
install memory maps from firmware data and for the virtual memory
regions respectively, drivers don't care which stage of the boot we're
at and just want to swap the existing memmap for a modified one.

efi_memmap_install() abstracts the details of how the new memory map
should be mapped and the existing one unmapped.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Cc: Taku Izumi 
Signed-off-by: Matt Fleming

efi: Split out EFI memory map functions into new file

2016-09-09T15:07:46+00:00

Also move the functions from the EFI fake mem driver since future
patches will require access to the memmap insertion code even if
CONFIG_EFI_FAKE_MEM isn't enabled.

This will be useful when we need to build custom EFI memory maps to
allow drivers to mark regions as reserved.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Cc: Taku Izumi 
Signed-off-by: Matt Fleming

efi: Add efi_memmap_init_late() for permanent EFI memmap

2016-09-09T15:07:43+00:00

Drivers need a way to access the EFI memory map at runtime. ARM and
arm64 currently provide this by remapping the EFI memory map into the
vmalloc space before setting up the EFI virtual mappings.

x86 does not provide this functionality which has resulted in the code
in efi_mem_desc_lookup() where it will manually map individual EFI
memmap entries if the memmap has already been torn down on x86,

  /*
   * If a driver calls this after efi_free_boot_services,
   * ->map will be NULL, and the target may also not be mapped.
   * So just always get our own virtual map on the CPU.
   *
   */
  md = early_memremap(p, sizeof (*md));

There isn't a good reason for not providing a permanent EFI memory map
for runtime queries, especially since the EFI regions are not mapped
into the standard kernel page tables.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Signed-off-by: Matt Fleming

efi: Refactor efi_memmap_init_early() into arch-neutral code

2016-09-09T15:06:38+00:00

Every EFI architecture apart from ia64 needs to setup the EFI memory
map at efi.memmap, and the code for doing that is essentially the same
across all implementations. Therefore, it makes sense to factor this
out into the common code under drivers/firmware/efi/.

The only slight variation is the data structure out of which we pull
the initial memory map information, such as physical address, memory
descriptor size and version, etc. We can address this by passing a
generic data structure (struct efi_memory_map_data) as the argument to
efi_memmap_init_early() which contains the minimum info required for
initialising the memory map.

In the process, this patch also fixes a few undesirable implementation
differences:

 - ARM and arm64 were failing to clear the EFI_MEMMAP bit when
   unmapping the early EFI memory map. EFI_MEMMAP indicates whether
   the EFI memory map is mapped (not the regions contained within) and
   can be traversed.  It's more correct to set the bit as soon as we
   memremap() the passed in EFI memmap.

 - Rename efi_unmmap_memmap() to efi_memmap_unmap() to adhere to the
   regular naming scheme.

This patch also uses a read-write mapping for the memory map instead
of the read-only mapping currently used on ARM and arm64. x86 needs
the ability to update the memory map in-place when assigning virtual
addresses to regions (efi_map_region()) and tagging regions when
reserving boot services (efi_reserve_boot_services()).

There's no way for the generic fake_mem code to know which mapping to
use without introducing some arch-specific constant/hook, so just use
read-write since read-only is of dubious value for the EFI memory map.

Tested-by: Dave Young  [kexec/kdump]
Tested-by: Ard Biesheuvel  [arm]
Acked-by: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Signed-off-by: Matt Fleming