summaryrefslogtreecommitdiffstats
path: root/arch/arm64/kernel/efi.c
Commit message (Collapse)AuthorAgeFilesLines
* arm64/efi: move virtmap init to early initcallArd Biesheuvel2015-01-221-58/+53Star
| | | | | | | | | | | Now that the create_mapping() code in mm/mmu.c is able to support setting up kernel page tables at initcall time, we can move the whole virtmap creation to arm64_enable_runtime_services() instead of having a distinct stage during early boot. This also allows us to drop the arm64-specific EFI_VIRTMAP flag. Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* arm64/efi: handle potential failure to remap memory mapArd Biesheuvel2015-01-161-4/+6
| | | | | | | | | | | | | | | | When remapping the UEFI memory map using ioremap_cache(), we have to deal with potential failure. Note that, even if the common case is for ioremap_cache() to return the existing linear mapping of the memory map, we cannot rely on that to be always the case, e.g., in the presence of a mem= kernel parameter. At the same time, remove a stale comment and move the memmap code together. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Salter <msalter@redhat.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* arm64/efi: remove idmap manipulations from UEFI codeArd Biesheuvel2015-01-121-31/+1Star
| | | | | | | | | | | Now that we have moved the call to SetVirtualAddressMap() to the stub, UEFI has no use for the ID map, so we can drop the code that installs ID mappings for UEFI memory regions. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64/efi: remove free_boot_services() and friendsArd Biesheuvel2015-01-121-122/+1Star
| | | | | | | | | | | 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. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64/efi: move SetVirtualAddressMap() to UEFI stubArd Biesheuvel2015-01-121-103/+127
| | | | | | | | | | | | | | | | | | | | | | 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 will only be called once (since the stub is not executed during kexec), and ensures that the UEFI state is identical between kexec and normal boot. This implies that the layout of the virtual mapping needs to be created by the stub as well. All regions are rounded up to a naturally aligned multiple of 64 KB (for compatibility with 64k pages kernels) and recorded in the UEFI memory map. The kernel proper reads those values and installs the mappings in a dedicated set of page tables that are swapped in during UEFI Runtime Services calls. Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Matt Fleming <matt.fleming@intel.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64/efi: add missing call to early_ioremap_reset()Ard Biesheuvel2015-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The early ioremap support introduced by patch bf4b558eba92 ("arm64: add early_ioremap support") failed to add a call to early_ioremap_reset() at an appropriate time. Without this call, invocations of early_ioremap etc. that are done too late will go unnoticed and may cause corruption. This is exactly what happened when the first user of this feature was added in patch f84d02755f5a ("arm64: add EFI runtime services"). The early mapping of the EFI memory map is unmapped during an early initcall, at which time the early ioremap support is long gone. Fix by adding the missing call to early_ioremap_reset() to setup_arch(), and move the offending early_memunmap() to right after the point where the early mapping of the EFI memory map is last used. Fixes: f84d02755f5a ("arm64: add EFI runtime services") Cc: <stable@vger.kernel.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
* arm64: dmi: set DMI string as dump stack arch descriptionArd Biesheuvel2014-11-051-0/+2
| | | | | | | | | | | This sets the DMI string, containing system type, serial number, firmware version etc. as dump stack arch description, so that oopses and other kernel stack dumps automatically have this information included, if available. Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64: dmi: Add SMBIOS/DMI supportYi Li2014-11-051-0/+13
| | | | | | | | | | | SMBIOS is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like. Signed-off-by: Yi Li <yi.li@linaro.org> Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES)Ard Biesheuvel2014-11-051-2/+0Star
| | | | | | | | | The EFI_CONFIG_TABLES bit already gets set by efi_config_init(), so there is no reason to set it again after this function returns successfully. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* arm64/efi: invert UEFI memory region reservation logicArd Biesheuvel2014-11-051-10/+10
| | | | | | | | | | | | | | | | | | | | | | Instead of reserving the memory regions based on which types we know need to be reserved, consider only regions of the following types as free for general use by the OS: EFI_LOADER_CODE EFI_LOADER_DATA EFI_BOOT_SERVICES_CODE EFI_BOOT_SERVICES_DATA EFI_CONVENTIONAL_MEMORY Note that this also fixes a problem with the original code, which would misidentify a EFI_RUNTIME_SERVICES_DATA region as not reserved if it does not have the EFI_MEMORY_RUNTIME attribute set. However, it is perfectly legal for the firmware not to request a virtual mapping for EFI_RUNTIME_SERVICES_DATA regions that contain configuration tables, in which case the EFI_MEMORY_RUNTIME attribute would not be set. Acked-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Merge branch 'next' into efi-next-mergeMatt Fleming2014-10-031-26/+18Star
|\ | | | | | | | | Conflicts: arch/x86/boot/compressed/eboot.c
| * arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format()Laszlo Ersek2014-10-031-20/+6Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An example log excerpt demonstrating the change: Before the patch: > Processing EFI memory map: > 0x000040000000-0x000040000fff [Loader Data] > 0x000040001000-0x00004007ffff [Conventional Memory] > 0x000040080000-0x00004072afff [Loader Data] > 0x00004072b000-0x00005fdfffff [Conventional Memory] > 0x00005fe00000-0x00005fe0ffff [Loader Data] > 0x00005fe10000-0x0000964e8fff [Conventional Memory] > 0x0000964e9000-0x0000964e9fff [Loader Data] > 0x0000964ea000-0x000096c52fff [Loader Code] > 0x000096c53000-0x00009709dfff [Boot Code]* > 0x00009709e000-0x0000970b3fff [Runtime Code]* > 0x0000970b4000-0x0000970f4fff [Runtime Data]* > 0x0000970f5000-0x000097117fff [Runtime Code]* > 0x000097118000-0x000097199fff [Runtime Data]* > 0x00009719a000-0x0000971dffff [Runtime Code]* > 0x0000971e0000-0x0000997f8fff [Conventional Memory] > 0x0000997f9000-0x0000998f1fff [Boot Data]* > 0x0000998f2000-0x0000999eafff [Conventional Memory] > 0x0000999eb000-0x00009af09fff [Boot Data]* > 0x00009af0a000-0x00009af21fff [Conventional Memory] > 0x00009af22000-0x00009af46fff [Boot Data]* > 0x00009af47000-0x00009af5bfff [Conventional Memory] > 0x00009af5c000-0x00009afe1fff [Boot Data]* > 0x00009afe2000-0x00009afe2fff [Conventional Memory] > 0x00009afe3000-0x00009c01ffff [Boot Data]* > 0x00009c020000-0x00009efbffff [Conventional Memory] > 0x00009efc0000-0x00009f14efff [Boot Code]* > 0x00009f14f000-0x00009f162fff [Runtime Code]* > 0x00009f163000-0x00009f194fff [Runtime Data]* > 0x00009f195000-0x00009f197fff [Boot Data]* > 0x00009f198000-0x00009f198fff [Runtime Data]* > 0x00009f199000-0x00009f1acfff [Conventional Memory] > 0x00009f1ad000-0x00009f1affff [Boot Data]* > 0x00009f1b0000-0x00009f1b0fff [Runtime Data]* > 0x00009f1b1000-0x00009fffffff [Boot Data]* > 0x000004000000-0x000007ffffff [Memory Mapped I/O] > 0x000009010000-0x000009010fff [Memory Mapped I/O] After the patch: > Processing EFI memory map: > 0x000040000000-0x000040000fff [Loader Data | | | | | |WB|WT|WC|UC] > 0x000040001000-0x00004007ffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x000040080000-0x00004072afff [Loader Data | | | | | |WB|WT|WC|UC] > 0x00004072b000-0x00005fdfffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00005fe00000-0x00005fe0ffff [Loader Data | | | | | |WB|WT|WC|UC] > 0x00005fe10000-0x0000964e8fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000964e9000-0x0000964e9fff [Loader Data | | | | | |WB|WT|WC|UC] > 0x0000964ea000-0x000096c52fff [Loader Code | | | | | |WB|WT|WC|UC] > 0x000096c53000-0x00009709dfff [Boot Code | | | | | |WB|WT|WC|UC]* > 0x00009709e000-0x0000970b3fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x0000970b4000-0x0000970f4fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x0000970f5000-0x000097117fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x000097118000-0x000097199fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009719a000-0x0000971dffff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x0000971e0000-0x0000997f8fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000997f9000-0x0000998f1fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x0000998f2000-0x0000999eafff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000999eb000-0x00009af09fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009af0a000-0x00009af21fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009af22000-0x00009af46fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009af47000-0x00009af5bfff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009af5c000-0x00009afe1fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009afe2000-0x00009afe2fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009afe3000-0x00009c01ffff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009c020000-0x00009efbffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009efc0000-0x00009f14efff [Boot Code | | | | | |WB|WT|WC|UC]* > 0x00009f14f000-0x00009f162fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x00009f163000-0x00009f194fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f195000-0x00009f197fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009f198000-0x00009f198fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f199000-0x00009f1acfff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009f1ad000-0x00009f1affff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009f1b0000-0x00009f1b0fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f1b1000-0x00009fffffff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x000004000000-0x000007ffffff [Memory Mapped I/O |RUN| | | | | | | |UC] > 0x000009010000-0x000009010fff [Memory Mapped I/O |RUN| | | | | | | |UC] The attribute bitmap is now displayed, in decoded form. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| * arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefiDave Young2014-10-031-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode should error out. At the same time move early_memunmap(memmap.map, mapsize) to the beginning of the function or it will leak early mem. Signed-off-by: Dave Young <dyoung@redhat.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| * arm64/efi: uefi_init error handling fixDave Young2014-10-031-3/+4
| | | | | | | | | | | | | | | | | | | | | | There's one early memmap leak in uefi_init error path, fix it and slightly tune the error handling code. Signed-off-by: Dave Young <dyoung@redhat.com> Acked-by: Mark Salter <msalter@redhat.com> Reported-by: Will Deacon <will.deacon@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2014-08-251-0/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "A couple of EFI fixes, plus misc fixes all around the map" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/arm64: Store Runtime Services revision firmware: Do not use WARN_ON(!spin_is_locked()) x86_32, entry: Clean up sysenter_badsys declaration x86/doc: Fix the 'tlb_single_page_flush_ceiling' sysconfig path x86/mm: Fix sparse 'tlb_single_page_flush_ceiling' warning and make the variable read-mostly x86/mm: Fix RCU splat from new TLB tracepoints
| * | efi/arm64: Store Runtime Services revisionSemen Protsenko2014-08-221-0/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | "efi" global data structure contains "runtime_version" field which must be assigned in order to use it later in Runtime Services virtual calls (virt_efi_* functions). Before this patch "runtime_version" was unassigned (0), so each Runtime Service virtual call that checks revision would fail. Signed-off-by: Semen Protsenko <semen.protsenko@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* / arm64: ignore DT memreserve entries when booting in UEFI modeLeif Lindholm2014-08-191-0/+2
|/ | | | | | | | | | | | UEFI provides its own method for marking regions to reserve, via the memory map which is also used to initialise memblock. So when using the UEFI memory map, ignore any memreserve entries present in the DT. Reported-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
* efi/arm64: Handle missing virtual mapping for UEFI System TableArd Biesheuvel2014-07-181-4/+24
| | | | | | | | | | | | If we cannot resolve the virtual address of the UEFI System Table, its physical offset must be missing from the virtual memory map, and there is really no point in proceeding with installing the virtual memory map and the runtime services dispatch table. So back out gracefully. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mark Salter <msalter@redhat.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi/arm64: Preserve FP/SIMD registers on UEFI runtime services callsArd Biesheuvel2014-07-071-13/+1Star
| | | | | | | | | | | | | | | | | According to the UEFI spec section 2.3.6.4, the use of FP/SIMD instructions is allowed, and should adhere to the AAPCS64 calling convention, which states that 'only the bottom 64 bits of each value stored in registers v8-v15 need to be preserved' (section 5.1.2). This applies equally to UEFI Runtime Services called by the kernel, so make sure the FP/SIMD register file is preserved in this case. We do this by enabling the wrappers for UEFI Runtime Services (CONFIG_EFI_RUNTIME_WRAPPERS) and inserting calls to kernel_neon_begin()and kernel_neon_end() into these wrappers. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* arm64: efi: only attempt efi map setup if booting via EFILeif Lindholm2014-05-231-0/+3
| | | | | | | | | | Booting a kernel with CONFIG_EFI enabled on a non-EFI system caused an oops with the current UEFI support code. Add the required test to prevent this. Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* arm64: add EFI runtime servicesMark Salter2014-04-301-0/+466
This patch adds EFI runtime support for arm64. This runtime support allows the kernel to access various EFI runtime services provided by EFI firmware. Things like reboot, real time clock, EFI boot variables, and others. This functionality is supported for little endian kernels only. The UEFI firmware standard specifies that the firmware be little endian. A future patch is expected to add support for big endian kernels running with little endian firmware. Signed-off-by: Mark Salter <msalter@redhat.com> [ Remove unnecessary cache/tlb maintenance. ] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-20 14:13:52 +0200