kernel/linux.git/drivers/firmware/efi/arm-init.c, branch linux-4.16.y

efi/arm/arm64: Add missing assignment of efi.config_table

2017-08-21T07:43:49+00:00

The ARM EFI init code never assigns the config_table member of the efi struct, which means the sysfs device node is missing, and other in-kernel users will not work correctly. So add the missing assignment. Note that, for now, the runtime and fw_vendor members are still omitted. This is deliberate: exposing physical addresses via sysfs nodes encourages behavior that we would like to avoid on ARM (given how it is more finicky about using correct memory attributes when mapping memory in userland that may be mapped by the kernel already as well). Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-6-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP

2017-08-21T07:43:49+00:00

On ARM, regions of memory that are described by UEFI as having special significance to the firmware itself are omitted from the linear mapping. This is necessary since we cannot guarantee that alternate mappings of the same physical region will use attributes that are compatible with the ones we use for the linear mapping, and aliases with mismatched attributes are prohibited by the architecture. The above does not apply to ACPI reclaim regions: such regions have no special significance to the firmware, and it is up to the OS to decide whether or not to preserve them after it has consumed their contents, and for how long, after which time the OS can use the memory in any way it likes. In the Linux case, such regions are preserved indefinitely, and are simply treated the same way as other 'reserved' memory types. Punching holes into the linear mapping causes page table fragmentation, which increases TLB pressure, and so we should avoid doing so if we can. So add a special case for regions of type EFI_ACPI_RECLAIM_MEMORY, and memblock_reserve() them instead of marking them MEMBLOCK_NOMAP. Signed-off-by: Ard Biesheuvel Acked-by: Mark Rutland Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures

2017-02-01T07:45:43+00:00

Since EFI_PROPERTIES_TABLE and EFI_MEMORY_ATTRIBUTES_TABLE deal with updating memory region attributes, it makes sense to call EFI_MEMORY_ATTRIBUTES_TABLE initialization function from the same place as EFI_PROPERTIES_TABLE. This also moves the EFI_MEMORY_ATTRIBUTES_TABLE initialization code to a more generic efi initialization path rather than ARM specific efi initialization. This is important because EFI_MEMORY_ATTRIBUTES_TABLE will be supported by x86 as well. Signed-off-by: Sai Praneeth Prakhya Signed-off-by: Matt Fleming Signed-off-by: Ard Biesheuvel Reviewed-by: Lee, Chun-Yi Cc: Borislav Petkov Cc: Fenghua Yu Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Ravi Shankar Cc: Ricardo Neri Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1485868902-20401-4-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi/arm*: Fix efi_init() error handling

2016-10-18T15:11:17+00:00

There's an early memmap() leak in the efi_init() error path, fix it. Signed-off-by: Yisheng Xie Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-4-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/arm64: Treat regions with WT/WC set but WB cleared as memory

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

Currently, memory regions are only recorded in the memblock memory table if they have the EFI_MEMORY_WB memory type attribute set. In case the region is of a reserved type, it is also marked as MEMBLOCK_NOMAP, which will leave it out of the linear mapping. However, memory regions may legally have the EFI_MEMORY_WT or EFI_MEMORY_WC attributes set, and the EFI_MEMORY_WB cleared, in which case the region in question is obviously backed by normal memory, but is not recorded in the memblock memory table at all. Since it would be useful to be able to identify any UEFI reported memory region using memblock_is_memory(), it makes sense to add all memory to the memblock memory table, and simply mark it as MEMBLOCK_NOMAP if it lacks the EFI_MEMORY_WB attribute. While implementing this, let's refactor the code slightly to make it easier to understand: replace is_normal_ram() with is_memory(), and make it return true for each region that has any of the WB|WT|WC bits set. (This follows the AArch64 bindings in the UEFI spec, which state that those are the attributes that map to normal memory) Also, replace is_reserve_region() with is_usable_memory(), and only invoke it if the region in question was identified as memory by is_memory() in the first place. The net result is the same (only reserved regions that are backed by memory end up in the memblock memory table with the MEMBLOCK_NOMAP flag set) but carried out in a more straightforward way. Finally, we remove the trailing asterisk in the EFI debug output. Keeping it clutters the code, and it serves no real purpose now that we no longer temporarily reserve BootServices code and data regions like we did in the early days of EFI support on arm64 Linux (which it inherited from the x86 implementation) Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm Tested-by: James Morse Reviewed-by: James Morse Signed-off-by: Matt Fleming

efi/arm*: esrt: Add missing call to efi_esrt_init()

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

ESRT support is built by default for all architectures that define CONFIG_EFI. However, this support was not wired up yet for ARM/arm64, since efi_esrt_init() was never called. So add the missing call. Signed-off-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Mark Rutland Cc: Peter Jones 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

efi/arm: Fix the format of EFI debug messages

2016-06-03T07:57:36+00:00

When both EFI and memblock debugging is enabled on the kernel command line: 'efi=debug memblock=debug' .. the debug messages for early_con look the following way: [ 0.000000] efi: 0x0000e1050000-0x0000e105ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x0000e1300000-0x0000e1300fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x0000e8200000-0x0000e827ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x008000000000-0x008001e7ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC] [ 0.000000] memblock_add: [0x00008000000000-0x00008001e7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c [ 0.000000] * ... Note the misplaced '*' line, which happened because the memblock debug message was printed while the EFI debug message was still being constructed.. This patch fixes the output to be the expected: [ 0.000000] efi: 0x0000e1050000-0x0000e105ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x0000e1300000-0x0000e1300fff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x0000e8200000-0x0000e827ffff [Memory Mapped I/O |RUN| | | | | | | | | | |UC] [ 0.000000] efi: 0x008000000000-0x008001e7ffff [Runtime Data |RUN| | | | | | | |WB|WT|WC|UC]* [ 0.000000] memblock_add: [0x00008000000000-0x00008001e7ffff] flags 0x0 early_init_dt_add_memory_arch+0x54/0x5c ... Note how the '*' is now in the proper EFI debug message line. Signed-off-by: Dennis Chen Signed-off-by: Matt Fleming Acked-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Dan Williams Cc: Linus Torvalds Cc: Mark Salter Cc: Peter Zijlstra Cc: Steve Capper Cc: Steve McIntyre Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1464690224-4503-3-git-send-email-matt@codeblueprint.co.uk [ Made the changelog more readable. ] Signed-off-by: Ingo Molnar

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2016-05-17T00:17:24+00:00

Pull arm64 updates from Will Deacon: - virt_to_page/page_address optimisations - support for NUMA systems described using device-tree - support for hibernate/suspend-to-disk - proper support for maxcpus= command line parameter - detection and graceful handling of AArch64-only CPUs - miscellaneous cleanups and non-critical fixes * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (92 commits) arm64: do not enforce strict 16 byte alignment to stack pointer arm64: kernel: Fix incorrect brk randomization arm64: cpuinfo: Missing NULL terminator in compat_hwcap_str arm64: secondary_start_kernel: Remove unnecessary barrier arm64: Ensure pmd_present() returns false after pmd_mknotpresent() arm64: Replace hard-coded values in the pmd/pud_bad() macros arm64: Implement pmdp_set_access_flags() for hardware AF/DBM arm64: Fix typo in the pmdp_huge_get_and_clear() definition arm64: mm: remove unnecessary EXPORT_SYMBOL_GPL arm64: always use STRICT_MM_TYPECHECKS arm64: kvm: Fix kvm teardown for systems using the extended idmap arm64: kaslr: increase randomization granularity arm64: kconfig: drop CONFIG_RTC_LIB dependency arm64: make ARCH_SUPPORTS_DEBUG_PAGEALLOC depend on !HIBERNATION arm64: hibernate: Refuse to hibernate if the boot cpu is offline arm64: kernel: Add support for hibernate/suspend-to-disk PM / Hibernate: Call flush_icache_range() on pages restored in-place arm64: Add new asm macro copy_page arm64: Promote KERNEL_START/KERNEL_END definitions to a header file arm64: kernel: Include _AC definition in page.h ...

efi/arm-init: Reserve rather than unmap the memory map for ARM as well

2016-04-28T09:34:05+00:00

Now that ARM has a fully functional memremap() implementation, there is no longer a need to remove the UEFI memory map from the linear mapping in order to be able to create a permanent mapping for it using generic code. So remove the 'IS_ENABLED(CONFIG_ARM)' conditional we added in: 7cc8cbcf82d1 ("efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping") ... and revert to using memblock_reserve() for both ARM and arm64. Signed-off-by: Ard Biesheuvel Signed-off-by: Matt Fleming Cc: Borislav Petkov Cc: Leif Lindholm Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-31-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar