[PATCH v3 07/13] arm64/efi: move SetVirtualAddressMap() to UEFI stub

In order to support kexec, the kernel needs to be able to deal with the state of the UEFI firmware after SetVirtualAddressMap() has been called. To avoid having separate code paths for non-kexec and kexec, let's move the call to SetVirtualAddressMap() to the stub: this will guarantee us that it

[PATCH v3 00/13] arm64: stable UEFI mappings for kexec

This is v3 of the series to update the UEFI memory map handling for the arm64 architecture so that: - virtual mappings of UEFI Runtime Services are stable across kexec - userland mappings via /dev/mem use cache attributes that are compatible with the memory type of the UEFI memory map entry -

[PATCH v3 01/13] arm64/mm: add explicit struct_mm argument to __create_mapping()

Currently, swapper_pg_dir and idmap_pg_dir share the init_mm mm_struct instance. To allow the introduction of other pg_dir instances, for instance, for UEFI's mapping of Runtime Services, make the struct_mm instance an explicit argument that gets passed down to the pmd and pte instantiation

[PATCH v3 08/13] arm64/efi: remove free_boot_services() and friends

Now that we are calling SetVirtualAddressMap() from the stub, there is no need to reserve boot-only memory regions, which implies that there is also no reason to free them again later. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi.c | 123

[PATCH v3 05/13] efi: add common infrastructure for stub-installed virtual mapping

This introduces the common infrastructure to be shared between arm64 and ARM that wires up the UEFI memory map into system RAM discovery, virtual mappings for Runtime Services and aligning cache attributes between kernel and userland (/dev/mem) mappings for regions owned by UEFI. Signed-off-by:

[PATCH v3 11/13] arm64/efi: use plain memblock API for adding and removing reserved RAM

The memblock API is agnostic of page size, so we can use it on both 4 KB and 64 KB granule kernels to install all UEFI memory regions (EFI_MEMORY_WB) using memblock_add(), and the memblock layer will stitch all unaligned regions together. Then we start punching holes in it for the reserved

[PATCH v3 04/13] efi: split off remapping code from efi_config_init()

Split of the remapping code from efi_config_init() so that the caller can perform its own remapping. This is necessary to correctly handle virtually remapped UEFI memory regions under kexec, as efi.systab will have been updated to a virtual address. Signed-off-by: Ard Biesheuvel

[PATCH v3 10/13] arm64/efi: use UEFI memory map unconditionally if available

On systems that boot via UEFI, all memory nodes are deleted from the device tree, and instead, the size and location of system RAM is derived from the UEFI memory map. This is handled by reserve_regions, which not only reserves parts of memory that UEFI declares as reserved, but also installs the

[PATCH v3 03/13] arm64: improve CONFIG_STRICT_DEVMEM handling

Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by: - allowing read-only access to parts of System RAM that are not considered memory by the kernel, this is mainly intended for exposing UEFI Configuration tables to userland; - avoid using non-cached mappings for those

[PATCH v3 12/13] efi: efistub: allow allocation alignment larger than EFI_PAGE_SIZE

On systems with 64 KB pages, it is preferable for UEFI memory map entries to be 64 KB aligned multiples of 64 KB, because it relieves us of having to deal with the residues. So, if EFI_ALLOC_ALIGN is #define'd by the platform, use it to round up all memory allocations made. Signed-off-by: Ard

[PATCH v3 06/13] efi: register iomem resources for UEFI reserved regions

Register memory regions reserved by UEFI as IORESOURCE_MEM resources, so that they are reserved for other uses, and also makes them turn up in /proc/iomem. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- drivers/firmware/efi/virtmap.c | 36 1 file

Re: [efi:next 2/3] arch/x86/boot/compressed/eboot.c:26:16: sparse: incorrect type in return expression (different modifiers)

On Tue, Nov 18, 2014 at 12:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: No, the test case looks correct now. You may want to add a conflicting definition, for completeness, as that is an important case for sparse to verify. So you could just add static void *pure1(void); //

Re: [efi:next 2/3] arch/x86/boot/compressed/eboot.c:26:16: sparse: incorrect type in return expression (different modifiers)

On 18 November 2014 17:09, Christopher Li spa...@chrisli.org wrote: On Tue, Nov 18, 2014 at 12:24 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: No, the test case looks correct now. You may want to add a conflicting definition, for completeness, as that is an important case for sparse

Re: [PATCH v2 1/3] firmware loader: Introduce new API - request_firmware_abort()

On Tue, Nov 18, 2014 at 06:31:38AM +, Kweh, Hock Leong wrote: -Original Message- From: Matt Fleming [mailto:m...@console-pimps.org] Sent: Monday, November 17, 2014 11:12 PM - Only doing module unload is required to be aware of this synchronization - Ensuring the call

Re: [efi:next 2/3] arch/x86/boot/compressed/eboot.c:26:16: sparse: incorrect type in return expression (different modifiers)

On Wed, Nov 19, 2014 at 12:38 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: Well, that is how sparse currently treats it, and I think that is correct. If an extern declaration in a .h file specifies __pure, then GCC may legally emit fewer calls to that function than appear in the source.