Re: [PATCH V6 6/8] Add EFI stub for ARM

2014-01-14 Thread Ard Biesheuvel
On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote: This patch adds EFI stub support for the ARM Linux kernel. The EFI stub operates similarly to the x86 stub: it is a shim between the EFI firmware and the normal zImage entry point, and sets up the environment that the zImage is

Re: [PATCH V6 6/8] Add EFI stub for ARM

2014-01-15 Thread Ard Biesheuvel
On 15 January 2014 03:16, Roy Franz roy.fr...@linaro.org wrote: On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz roy.fr...@linaro.org wrote: On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 10 January 2014 17:30, Roy Franz roy.fr...@linaro.org wrote: This patch

Re: [PATCH 21/22] arm: efistub: ignore dtb= when UEFI SecureBoot is enabled

2014-02-05 Thread Ard Biesheuvel
On 5 February 2014 18:04, Leif Lindholm leif.lindh...@linaro.org wrote: From: Ard Biesheuvel ard.biesheu...@linaro.org Loading unauthenticated FDT blobs directly from storage is a security hazard, so this should only be allowed when running with UEFI Secure Boot disabled. Signed-off-by: Ard

Re: EFI_STUB fails to boot non-EFI on arm64

2014-05-23 Thread Ard Biesheuvel
On 23 May 2014 17:45, Leif Lindholm leif.lindh...@linaro.org wrote: On Fri, May 23, 2014 at 05:17:39PM +0200, Ard Biesheuvel wrote: Can we add another of detecting whether it's an EFI application and avoid calling efi_init()? I can see x86 sets some efi_loader_signature string

[RFC PATCH 1/4] efi/x86: efistub: move shared dependencies to asm/efi.h

2014-06-16 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/x86/boot

[RFC PATCH 3/4] efi: efistub: refactor stub components

2014-06-16 Thread Ard Biesheuvel
which were formerly relying on the #includor to include the correct header files - remove all static modifiers from functions which will need to be externally visible once we move to a static library Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-stub.c

Re: [RFC PATCH 4/4] efi: efistub: convert into static library

2014-06-16 Thread Ard Biesheuvel
On 16 June 2014 17:14, Ard Biesheuvel ard.biesheu...@linaro.org wrote: This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building the shared code as a static library. The x86 code uses a stub built into the boot

Re: [PATCH] efi: fix pointer type errors in fdt_uefi_find_params()

2014-06-18 Thread Ard Biesheuvel
On 18 June 2014 11:02, Matt Fleming m...@console-pimps.org wrote: On Fri, 13 Jun, at 04:54:59PM, Ard Biesheuvel wrote: Fix two instances of pointer type errors, a harmless one where a const void* value is assigned to a non-const void* variable, and a not-so-harmless one where we pass

Re: [PATCH] efi/arm64: efistub: remove local copy of linux_banner

2014-06-18 Thread Ard Biesheuvel
On 18 June 2014 10:50, Matt Fleming m...@console-pimps.org wrote: On Fri, 13 Jun, at 01:11:51PM, Ard Biesheuvel wrote: The shared efistub code for ARM and arm64 contains a local copy of linux_banner, allowing it to be referenced from separate executables such as the ARM decompressor. However

Re: [PATCH] efi: fix pointer type errors in fdt_uefi_find_params()

2014-06-18 Thread Ard Biesheuvel
On 18 June 2014 11:28, Matt Fleming m...@console-pimps.org wrote: On Wed, 18 Jun, at 11:06:09AM, Ard Biesheuvel wrote: You say potato, I say po-tah-to? But seriously, whichever you prefer ... $ git grep const void | wc -l 4441 $ git grep void const | wc -l 50 I say potato, you say

[PATCH 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code

2014-06-23 Thread Ard Biesheuvel
In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime.c. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/x86/platform/efi/efi.c| 144 +-- drivers

[PATCH 2/2] efi/arm64: preserve NEON registers on UEFI runtime services calls

2014-06-23 Thread Ard Biesheuvel
UEFI Runtime Services function calls may clobber the contents of the NEON register file, so we need to make sure that we preserve/restore them when performing such a function call. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/include/asm/efi.h | 21

[PATCH 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-23 Thread Ard Biesheuvel
, and adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers. The first patch moves the existing x86 versions of those wrappers to generic code, so that the second patch can easily enable them by supplying a definition for efi_call_virt and adding a call to efi_native_runtime_setup(). Ard

Re: [PATCH 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-23 Thread Ard Biesheuvel
On 23 June 2014 16:18, Ard Biesheuvel ard.biesheu...@linaro.org wrote: The current UEFI implementation for arm64 fails to preserve/restore the contents of the NEON register file, which may result in data corruption, especially now that those contents are lazily restored for user processes

Re: [RFC PATCH 4/4] efi: efistub: convert into static library

2014-06-25 Thread Ard Biesheuvel
Hey Matt, On 25 jun. 2014, at 22:34, Matt Fleming m...@console-pimps.org wrote: On Mon, 16 Jun, at 05:14:48PM, Ard Biesheuvel wrote: This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building the shared code

Re: [efi:next 6/7] drivers/firmware/efi/runtime.c:19:21: fatal error: asm/efi.h: No such file or directory

2014-06-25 Thread Ard Biesheuvel
On 25 June 2014 23:53, kbuild test robot fengguang...@intel.com wrote: tree: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git next head: 8922cc07b558b167bc8f9e176c1a0b49acc5694f commit: 012e96bf2f05b3652ef02cf3df80b7a63cced0af [6/7] efi/x86: move UEFI Runtime Services

[PATCH v2 2/2] efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls

2014-06-26 Thread Ard Biesheuvel
Runtime Services called by the kernel, so make sure the FP/SIMD register file is preserved in this case. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/efi.h | 21 + arch/arm64/kernel/efi.c | 14

[PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code

2014-06-26 Thread Ard Biesheuvel
In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/x86/Kconfig| 1 + arch/x86/platform/efi/efi.c

[PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-26 Thread Ard Biesheuvel
UEFI/AAPCS spec sections Ard Biesheuvel (2): efi/x86: move UEFI Runtime Services wrappers to generic code efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls arch/arm64/Kconfig | 1 + arch/arm64/include/asm/efi.h| 21 + arch/arm64/kernel

Re: [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls

2014-06-26 Thread Ard Biesheuvel
On 26 June 2014 15:58, Mark Salter msal...@redhat.com wrote: On Thu, 2014-06-26 at 12:09 +0200, Ard Biesheuvel wrote: The current UEFI implementation for arm64 fails to preserve/restore the contents of the NEON register file, Does the current implementation actually use NEON registers? I

[PATCH v2 2/5] efi/x86: efistub: move shared dependencies to asm/efi.h

2014-06-26 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/x86/boot

[PATCH v2 1/5] efi/arm64: avoid EFI_ERROR as a generic return code

2014-06-26 Thread Ard Biesheuvel
As EFI_ERROR is not a UEFI result code but a local invention only intended to allow get_dram_base() to signal failure, we should not use it elsewhere. Replace with EFI_LOAD_ERROR. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-stub.c | 2 +- 1 file changed, 1

[PATCH v2 3/5] efi/arm64: efistub: move shared dependencies to asm/efi.h

2014-06-26 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/arm64/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/include

[PATCH v2 4/5] efi: efistub: refactor stub components

2014-06-26 Thread Ard Biesheuvel
which were formerly relying on the #includor to include the correct header files - remove all static modifiers from functions which will need to be externally visible once we move to a static library Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-stub.c

[PATCH v2 0/5] efistub: convert into static library

2014-06-26 Thread Ard Biesheuvel
be returned by get_dram_base() and efi_entry() - added a section to libstub Makefile to clean CFLAGS of stack protecter and other options that are inappropriate for the stub - rebased onto the UEFI Runtime Services NEON patches (re)posted earlier today Ard Biesheuvel (5): efi/arm64: avoid

[PATCH v2 5/5] efi: efistub: convert into static library

2014-06-26 Thread Ard Biesheuvel
is linked into the decompressor. In the arm64 case, the stub is part of the kernel proper so the library is linked into the kernel proper as well. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/Kconfig | 1 + arch/arm64/Makefile

Re: [PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code

2014-07-01 Thread Ard Biesheuvel
On 1 July 2014 15:30, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 12:09:05PM, Ard Biesheuvel wrote: In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard

Re: [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls

2014-07-01 Thread Ard Biesheuvel
On 1 July 2014 15:26, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 12:09:04PM, Ard Biesheuvel wrote: The current UEFI implementation for arm64 fails to preserve/restore the contents of the NEON register file, which may result in data corruption, especially now that those

Re: [PATCH v2 4/5] efi: efistub: refactor stub components

2014-07-01 Thread Ard Biesheuvel
On 1 July 2014 17:11, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 04:23:36PM, Ard Biesheuvel wrote: In order to move from the #include ../../../x.c anti-pattern used by both the x86 and arm64 versions of the stub to a static library linked into either the kernel proper

[PATCH 2/2] efi: implement mandatory locking for UEFI Runtime Services

2014-07-02 Thread Ard Biesheuvel
According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- drivers/firmware/efi/runtime-wrappers.c | 109

[PATCH 1/2] efi/arm64: fix potential NULL dereference of efi.systab

2014-07-02 Thread Ard Biesheuvel
We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but then go on an dereference it anyway. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/efi.c

Re: [PATCH v2 5/5] efi: efistub: convert into static library

2014-07-02 Thread Ard Biesheuvel
On 2 July 2014 13:15, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 04:23:37PM, Ard Biesheuvel wrote: This patch changes both x86 and arm64 efistub implementations from #including shared .c files under drivers/firmware/efi to building the shared code as a static library

Re: [PATCH v2 5/5] efi: efistub: convert into static library

2014-07-02 Thread Ard Biesheuvel
Would something like this ifneq ($(CONFIG_EFI_STUB)$(CONFIG_EFI_ARMSTUB),nn) obj-y += libstub/ endif be too hideous? On 2 July 2014 13:23, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 2 July 2014 13:15, Matt Fleming m...@console-pimps.org wrote: On Thu, 26 Jun, at 04:23:37PM, Ard

[PATCH v3 3/5] efi/arm64: efistub: Move shared dependencies to asm/efi.h

2014-07-02 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/arm64/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Signed-off-by: Matt

[PATCH v3 4/5] efi: efistub: refactor stub components

2014-07-02 Thread Ard Biesheuvel
which were formerly relying on the #includor to include the correct header files - remove all static modifiers from functions which will need to be externally visible once we move to a static library Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-stub.c

[PATCH v3 0/5] efistub: convert into static library

2014-07-02 Thread Ard Biesheuvel
by get_dram_base() and efi_entry() - added a section to libstub Makefile to clean CFLAGS of stack protecter and other options that are inappropriate for the stub - rebased onto the UEFI Runtime Services NEON patches (re)posted earlier today Ard Biesheuvel (5): efi/arm64: Avoid EFI_ERROR as a generic

[PATCH v3 2/5] efi/x86: efistub: Move shared dependencies to asm/efi.h

2014-07-02 Thread Ard Biesheuvel
This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers/firmware/efi into a static library. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Signed-off-by: Matt Fleming

[PATCH v3 5/5] efi: efistub: convert into static library

2014-07-02 Thread Ard Biesheuvel
is linked into the decompressor. In the arm64 case, the stub is part of the kernel proper so the library is linked into the kernel proper as well. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/Kconfig | 5 + arch/arm64/Makefile

[PATCH v3 1/5] efi/arm64: Avoid EFI_ERROR as a generic return code

2014-07-02 Thread Ard Biesheuvel
As EFI_ERROR is not a UEFI result code but a local invention only intended to allow get_dram_base() to signal failure, we should not use it elsewhere. Replace with EFI_LOAD_ERROR. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Signed-off-by: Matt Fleming matt.flem...@intel.com --- arch

Re: [PATCH v2 2/5] efi/x86: efistub: move shared dependencies to asm/efi.h

2014-07-02 Thread Ard Biesheuvel
On 2 July 2014 14:59, Mark Salter msal...@redhat.com wrote: On Thu, 2014-06-26 at 16:23 +0200, Ard Biesheuvel wrote: This moves definitions depended upon both by code under arch/x86/boot and under drivers/firmware/efi to asm/efi.h. This is in preparation of turning the stub code under drivers

Re: [PATCH 1/2] efi/arm64: fix potential NULL dereference of efi.systab

2014-07-03 Thread Ard Biesheuvel
On 2 July 2014 16:29, Mark Salter msal...@redhat.com wrote: On Wed, 2014-07-02 at 12:13 +0200, Ard Biesheuvel wrote: On 2 July 2014 12:10, Ard Biesheuvel ard.biesheu...@linaro.org wrote: We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but then go

[PATCH v2] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-04 Thread Ard Biesheuvel
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

Re: [PATCH 1/2] efi/arm64: fix potential NULL dereference of efi.systab

2014-07-04 Thread Ard Biesheuvel
On 4 July 2014 15:38, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Jul 02, 2014 at 11:10:01AM +0100, Ard Biesheuvel wrote: We assign efi.systab using efi_lookup_mapped_addr(), and test for !NULL, but then go on an dereference it anyway. Signed-off-by: Ard Biesheuvel ard.biesheu

Re: [PATCH v2] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-04 Thread Ard Biesheuvel
(adding Catalin) On 4 July 2014 16:42, Mark Salter msal...@redhat.com wrote: On Fri, 2014-07-04 at 12:16 +0200, Ard Biesheuvel wrote: 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

[PATCH v3] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-04 Thread Ard Biesheuvel
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

Re: [PATCH v2 2/2] efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls

2014-07-04 Thread Ard Biesheuvel
On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote: 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

Re: [PATCH v2 2/2] efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls

2014-07-04 Thread Ard Biesheuvel
On 4 July 2014 18:59, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Jul 04, 2014 at 04:51:31PM +0100, Ard Biesheuvel wrote: On 4 July 2014 17:45, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Jun 26, 2014 at 11:09:06AM +0100, Ard Biesheuvel wrote: According to the UEFI spec

Re: [PATCH v3] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-04 Thread Ard Biesheuvel
On 4 July 2014 19:01, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Jul 04, 2014 at 05:52:36PM +0100, Mark Salter wrote: On Fri, 2014-07-04 at 17:25 +0200, Ard Biesheuvel wrote: If we cannot resolve the virtual address of the UEFI System Table, its physical offset must be missing

[PATCH v3 2/2] efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls

2014-07-04 Thread Ard Biesheuvel
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

[PATCH v3 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code

2014-07-04 Thread Ard Biesheuvel
In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime.c. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/x86/Kconfig| 1 + arch/x86/platform/efi/efi.c

[PATCH v3 0/2] efi/arm64: FP/SIMD preserve/restore during UEFI Runtime Services

2014-07-04 Thread Ard Biesheuvel
v3: - improve commit message for patch #2 and add Catalin's ack v2: - add Kconfig symbol EFI_RUNTIME_WRAPPERS so we don't break ia64 by enabling it unconditionally Ard Biesheuvel (2): efi/x86: move UEFI Runtime Services wrappers to generic code efi/arm64: preserve FP/SIMD registers on UEFI

Re: [PATCH 2/2] efi: implement mandatory locking for UEFI Runtime Services

2014-07-08 Thread Ard Biesheuvel
On 7 July 2014 22:43, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 7 July 2014 22:29, Matt Fleming m...@console-pimps.org wrote: On Wed, 02 Jul, at 12:10:02PM, Ard Biesheuvel wrote: According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant

Re: [PATCH 2/2] efi: implement mandatory locking for UEFI Runtime Services

2014-07-08 Thread Ard Biesheuvel
On 8 July 2014 11:29, Matt Fleming m...@console-pimps.org wrote: On Tue, 08 Jul, at 10:54:13AM, Ard Biesheuvel wrote: After doing a bit more research, I still think there is work needed if we aim to adhere to the UEFI spec, or at least be safe from the hazards it points out. Note that I

[PATCH v2] efi: implement mandatory locking for UEFI Runtime Services

2014-07-08 Thread Ard Biesheuvel
According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- So this is v2 of the UEFI Runtime Services serialization patch: this time, I

Re: [PATCH v2] efi: implement mandatory locking for UEFI Runtime Services

2014-07-08 Thread Ard Biesheuvel
On 8 July 2014 13:21, Ard Biesheuvel ard.biesheu...@linaro.org wrote: According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org

[PATCH v3] efi: implement mandatory locking for UEFI Runtime Services

2014-07-11 Thread Ard Biesheuvel
-by: Ard Biesheuvel ard.biesheu...@linaro.org --- v3: Keep value of in_nmi() cached in local scope to help the compiler understand that it cannot change while the function is active v2: So this is v2 of the UEFI Runtime Services serialization patch: this time, I use a single spinlock rather than a set

Re: [PATCH] x86/efi: autoload efivars

2014-07-11 Thread Ard Biesheuvel
On 9 July 2014 08:40, joeyli j...@suse.com wrote: On Tue, Jul 08, 2014 at 01:19:42PM +0100, Ben Hutchings wrote: On Tue, 2014-07-08 at 11:14 +0100, Matt Fleming wrote: On Tue, 08 Jul, at 11:00:58AM, Lee, Chun-Yi wrote: [...] --- a/arch/x86/platform/efi/efi.c +++

Re: [PATCH] x86/efi: autoload efivars

2014-07-11 Thread Ard Biesheuvel
On 11 July 2014 09:52, Matt Fleming m...@console-pimps.org wrote: On Fri, 11 Jul, at 09:47:23AM, Ard Biesheuvel wrote: Hi all, I tested the version that is in Matt's -next now and it works fine on arm64. Great, thanks Ard. May I add your Tested-by to the patch? Sure, Tested-by: Ard

[PATCH] efi/arm64: efistub: don't abort if base of DRAM is occupied

2014-07-14 Thread Ard Biesheuvel
If we fail to relocate the kernel Image to its preferred offset of TEXT_OFFSET bytes above the base of DRAM, accept the lowest alternative mapping available instead of aborting. We may lose a bit of memory at the low end, but we can still proceed normally otherwise. Signed-off-by: Ard Biesheuvel

Re: [PATCH] efi/arm64: efistub: don't abort if base of DRAM is occupied

2014-07-14 Thread Ard Biesheuvel
On 14 July 2014 17:25, Ard Biesheuvel ard.biesheu...@linaro.org wrote: If we fail to relocate the kernel Image to its preferred offset of TEXT_OFFSET bytes above the base of DRAM, accept the lowest alternative mapping available instead of aborting. We may lose a bit of memory at the low end

[PATCH 0/2] arm64: use Image header fields in EFI stub

2014-07-14 Thread Ard Biesheuvel
at exactly the right offset, but the allocation is actually too small to satisfy the requirement imposed by image_size as set in the header. Ard Biesheuvel (2): arm64: add C struct definition for Image header arm64/efi: efistub: get text offset and image size from the Image header arch

[PATCH 1/2] arm64: add C struct definition for Image header

2014-07-14 Thread Ard Biesheuvel
In order to be able to interpret the Image header from C code, we need a struct definition that reflects the specification for Image headers as laid out in Documentation/arm64/booting.txt. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/include/asm/image_hdr.h | 75

[PATCH 2/2] arm64/efi: efistub: get text offset and image size from the Image header

2014-07-14 Thread Ard Biesheuvel
where Image happens to be loaded at exactly the right offset, but the allocation is actually too small to satisfy the requirement imposed by image_size as set in the header. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/Makefile | 2 -- arch/arm64/kernel/efi

Re: [PATCH 1/2] arm64: add C struct definition for Image header

2014-07-14 Thread Ard Biesheuvel
On 14 July 2014 18:58, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Mon, Jul 14, 2014 at 05:17:50PM +0100, Ard Biesheuvel wrote: In order to be able to interpret the Image header from C code, we need a struct definition that reflects the specification for Image headers as laid out

Re: [PATCH 2/2] arm64/efi: efistub: get text offset and image size from the Image header

2014-07-14 Thread Ard Biesheuvel
On 14 July 2014 18:54, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote: The EFI stub for arm64 needs to behave like an ordinary bootloader in the sense that it needs to use the EFI environment and the Image header at runtime

Re: [PATCH 2/2] arm64/efi: efistub: get text offset and image size from the Image header

2014-07-15 Thread Ard Biesheuvel
On 14 July 2014 20:29, Mark Rutland mark.rutl...@arm.com wrote: On Mon, Jul 14, 2014 at 06:35:32PM +0100, Ard Biesheuvel wrote: On 14 July 2014 18:54, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote: The EFI stub for arm64

[PATCH] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-15 Thread Ard Biesheuvel
be loaded at the expected offset. So instead, jump to 'stext' directly, which is at the base of the PE/COFF .text section. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-entry.S | 2 +- arch/arm64/kernel/head.S | 10 ++ 2 files changed, 7 insertions

[PATCH v2] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-15 Thread Ard Biesheuvel
with a reference to 'stext_offset' Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-entry.S | 3 ++- arch/arm64/kernel/head.S | 10 ++ 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S

[PATCH] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-07-15 Thread Ard Biesheuvel
by the payload will be zero initialised by the EFI loader. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 78ddae28b090

Re: [PATCH] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-15 Thread Ard Biesheuvel
On 15 July 2014 13:31, Mark Rutland mark.rutl...@arm.com wrote: diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S index 619b1dd7bcde..6ef541731d9e 100644 --- a/arch/arm64/kernel/efi-entry.S +++ b/arch/arm64/kernel/efi-entry.S @@ -61,7 +61,7 @@

[RFC PATCH] arm64/efi: efistub: reuse EFI mapping for Image if it is lower

2014-07-15 Thread Ard Biesheuvel
mapping has sufficient size, we add 2 megs + TEXT_OFFSET of padding to the PE/COFF .text section, this should be sufficient to cover rounding and adding TEXT_OFFSET. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- This was tested on a Foundation Model using the patch below, which forces

Re: [RFC PATCH] arm64/efi: efistub: reuse EFI mapping for Image if it is lower

2014-07-16 Thread Ard Biesheuvel
On 16 July 2014 16:10, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-15 at 18:50 +0200, Ard Biesheuvel wrote: The EFI loader may load Image at any available offset. This means Image may reside very close to or at the base of DRAM, in which case the relocation done by efi_entry

Re: [PATCH v2] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-16 Thread Ard Biesheuvel
On 16 July 2014 23:03, Mark Salter msal...@redhat.com wrote: On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote: On 16 July 2014 21:45, Mark Salter msal...@redhat.com wrote: On Wed, 2014-07-16 at 16:53 +0100, Mark Rutland wrote: On Wed, Jul 16, 2014 at 03:51:37PM +0100, Mark Salter

Re: [PATCH v3] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-18 Thread Ard Biesheuvel
On 7 July 2014 22:38, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 7 July 2014 22:11, Matt Fleming m...@console-pimps.org wrote: On Sat, 05 Jul, at 08:25:35AM, Catalin Marinas wrote: OK, I’ll leave it to Matt then together with the other EFI patches he’s already queuing. Thanks guys

Re: [PATCH v3] efi/arm64: handle missing virtual mapping for UEFI System Table

2014-07-18 Thread Ard Biesheuvel
On 18 July 2014 21:31, Matt Fleming m...@console-pimps.org wrote: On Fri, 18 Jul, at 08:42:27PM, Ard Biesheuvel wrote: Hey Matt, I was wondering if you're on track to queue up your -next branch for 3.17? If so, could you please include $subject? And if you don't mind, could you squash

[RFC PATCH 02/10] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-07-21 Thread Ard Biesheuvel
by the payload will be zero initialised by the EFI loader. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 5cd1f3491df5

[RFC PATCH 04/10] arm64: add EFI little endian constants to linker script

2014-07-21 Thread Ard Biesheuvel
-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/image.h | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h index 8fae0756e175..f5a2f298810d 100644 --- a/arch/arm64/kernel/image.h +++ b/arch/arm64

[RFC PATCH 03/10] arm64: add macros to emit little endian ASM constants

2014-07-21 Thread Ard Biesheuvel
The Image header contains many constants that should be emitted in little endian regardless of the endianness of the kernel. Add helper macros le16, le32 and le64 to asm/assembler.h to aid with this. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/include/asm/assembler.h

[RFC PATCH 00/10] arm64: boot BE kernels from UEFI

2014-07-21 Thread Ard Biesheuvel
this. There is some trickery regarding en-/disabling caches and MMU and surely I have gotten something wrong there. Ard Biesheuvel (10): arm64/efi: efistub: jump to 'stext' directly, not through the header arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text arm64: add macros to emit

[RFC PATCH 01/10] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-21 Thread Ard Biesheuvel
with a reference to 'stext_offset' Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/efi-entry.S | 3 ++- arch/arm64/kernel/head.S | 10 ++ 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S

[RFC PATCH 09/10] arm64/efi: enable minimal UEFI Runtime Services for big endian

2014-07-21 Thread Ard Biesheuvel
This enables the UEFI Runtime Services needed to manipulate the non-volatile variable store when running under a BE kernel. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/include/asm/efi.h | 2 + arch/arm64/kernel/efi-be-call.S| 55 arch

[RFC PATCH 05/10] arm64/efi: update the PE/COFF header to be endian agnostic

2014-07-21 Thread Ard Biesheuvel
Update the PE/COFF header to use explicit little endian constants and use explicit little endian linker symbols so that the PE/COFF header is always emitted in little endian regardless of the endiannes of the kernel. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel

[RFC PATCH 10/10] arm64: Kconfig: enable UEFI on BE kernels

2014-07-21 Thread Ard Biesheuvel
This changes the Kconfig logic to allow EFI to be enabled on a BE kernel build. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/Kconfig | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index e9d8af2fc389

[RFC PATCH 07/10] arm64/efi: efistub: add support for booting a BE kernel

2014-07-21 Thread Ard Biesheuvel
and string functions. This is accomplished by building little endian versions of those support files and link them into a static library which is used by the inner stub build. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/Makefile | 7 +++- arch

Re: [PATCH v2] arm64/efi: efistub: jump to 'stext' directly, not through the header

2014-07-21 Thread Ard Biesheuvel
On 17 July 2014 16:09, Mark Salter msal...@redhat.com wrote: On Wed, 2014-07-16 at 23:13 +0200, Ard Biesheuvel wrote: On 16 July 2014 23:03, Mark Salter msal...@redhat.com wrote: On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote: On 16 July 2014 21:45, Mark Salter msal...@redhat.com

Re: [RFC PATCH 09/10] arm64/efi: enable minimal UEFI Runtime Services for big endian

2014-07-23 Thread Ard Biesheuvel
Runtime Services is that they are used by an installer (through efibootmgr) to program the kernel command line. Hence the choice for just these services in the minimal implementation. -- Ard. On Mon, Jul 21, 2014 at 04:16:24PM +0100, Ard Biesheuvel wrote: This enables the UEFI Runtime Services

Re: [RFC PATCH 09/10] arm64/efi: enable minimal UEFI Runtime Services for big endian

2014-07-23 Thread Ard Biesheuvel
On 07/23/2014 12:59 PM, Ard Biesheuvel wrote: On 23 July 2014 11:34, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, This is certainly a neat feature, and I definitely want to be able to boot BE kernels via UEFI. Good! However, I'm wary of calling EFI in a physical (i.e. idmap

[PATCH 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-07-29 Thread Ard Biesheuvel
that is not covered by the payload will be zero initialised by the PE/COFF loader. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index

[PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-29 Thread Ard Biesheuvel
If we cannot relocate the kernel Image to its preferred offset of base of DRAM plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still proceed normally otherwise. Signed-off-by: Ard Biesheuvel

[PATCH 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

2014-07-29 Thread Ard Biesheuvel
From: Mark Rutland mark.rutl...@arm.com In certain cases the cpu-release-addr of a CPU may not fall in the linear mapping (e.g. when the kernel is loaded above this address due to the presence of other images in memory). This is problematic for the spin-table code as it assumes that it can

Re: [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-29 Thread Ard Biesheuvel
On 29 July 2014 17:29, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote: If we cannot relocate the kernel Image to its preferred offset of base of DRAM plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus TEXT_OFFSET

Re: [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-29 Thread Ard Biesheuvel
On 29 July 2014 20:27, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote: On 29 July 2014 17:29, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote: If we cannot relocate the kernel Image to its preferred

Re: [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-29 Thread Ard Biesheuvel
On 29 July 2014 21:20, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote: On 29 July 2014 20:27, Mark Salter msal...@redhat.com wrote: On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote: On 29 July 2014 17:29, Mark Salter msal...@redhat.com

[PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-07-30 Thread Ard Biesheuvel
that is not covered by the payload will be zero initialised by the PE/COFF loader. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Acked-by: Mark Salter msal...@redhat.com --- arch/arm64/kernel/head.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel

[PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-30 Thread Ard Biesheuvel
If we cannot relocate the kernel Image to its preferred offset of base of DRAM plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still proceed normally otherwise. Signed-off-by: Ard Biesheuvel

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

2014-07-30 Thread Ard Biesheuvel
mark.rutl...@arm.com Tested-by: Mark Salter msal...@redhat.com [ardb: added (__force void *) cast] Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm64/kernel/smp_spin_table.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/arm64

[PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling

2014-07-30 Thread Ard Biesheuvel
. Changes in v2: - add (__force void *) cast to patch #1, as suggested in LAKML discussion - add tested-by/acked-by lines - rebased patch #3 onto efi-next Mark Rutland (1): arm64: spin-table: handle unmapped cpu-release-addrs Ard Biesheuvel (2): arm64/efi: efistub: cover entire static mem

Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

2014-07-30 Thread Ard Biesheuvel
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote: On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: From: Mark Rutland mark.rutl...@arm.com In certain cases the cpu-release-addr of a CPU may not fall in the linear mapping (e.g. when the kernel is loaded above

Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

2014-07-30 Thread Ard Biesheuvel
On 30 July 2014 14:00, Ard Biesheuvel ard.biesheu...@linaro.org wrote: On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote: On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: From: Mark Rutland mark.rutl...@arm.com In certain cases the cpu-release-addr of a CPU may

Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

2014-07-30 Thread Ard Biesheuvel
On 30 July 2014 14:49, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote: On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote: On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote: On 30 July 2014 13:30, Will Deacon

  1   2   3   4   5   6   7   8   9   10   >