Re: [PATCH v2 1/3] Documentation: arm: add UEFI support documentation

Hi Leif, On Thu, Oct 03, 2013 at 12:24:39PM +0100, Leif Lindholm wrote: This patch provides documentation of the [U]EFI runtime services and configuration features. Cc: linux-...@vger.kernel.org Signed-off-by: Leif Lindholm leif.lindh...@linaro.org Acked-by: Rob Landley r...@landley.net

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

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 and not rely on the linker or preprocessor to produce values for

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

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 in Documentation/arm64/booting.txt. Signed-off-by: Ard Biesheuvel

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

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 needs to behave like an ordinary bootloader in the sense

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

Hi Ard, On Tue, Jul 15, 2014 at 10:10:02AM +0100, Ard Biesheuvel wrote: After the EFI stub has done its business, it jumps into the kernel by branching to offset #0 of the loaded Image, which is where it expects to find the header containing a 'branch to stext' instruction. However, the

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

73812b654a07f497f71bd38dfb4a6753fb0ad23e Mon Sep 17 00:00:00 2001 From: Mark Rutland mark.rutl...@arm.com Date: Tue, 15 Jul 2014 11:32:53 +0100 Subject: [PATCH] arm64: spin-table: handle unmapped cpu-release-addrs 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] efi/arm64: efistub: don't abort if base of DRAM is occupied

On Tue, Jul 15, 2014 at 11:02:22AM +0100, Leif Lindholm wrote: On Mon, Jul 14, 2014 at 02:40:48PM -0400, Mark Salter wrote: On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote: If we fail to relocate the kernel Image to its preferred offset of TEXT_OFFSET bytes above the base of

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

On Tue, Jul 15, 2014 at 12:49:07PM +0100, Ard Biesheuvel wrote: 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

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

On Tue, Jul 15, 2014 at 03:23:26PM +0100, Mark Salter wrote: On Tue, 2014-07-15 at 14:54 +0100, Leif Lindholm wrote: On Tue, Jul 15, 2014 at 09:11:00AM -0400, Mark Salter wrote: On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote: @@ -273,6 +282,10 @@ static void __init

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

Hi Ard, On Tue, Jul 15, 2014 at 05:50:30PM +0100, 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() results in Image being moved up in memory, which is

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

On Wed, Jul 16, 2014 at 03:51:37PM +0100, Mark Salter wrote: On Tue, 2014-07-15 at 12:58 +0200, Ard Biesheuvel wrote: After the EFI stub has done its business, it jumps into the kernel by branching to offset #0 of the loaded Image, which is where it expects to find the header

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

Hi Ard, This is certainly a neat feature, and I definitely want to be able to boot BE kernels via UEFI. However, I'm wary of calling EFI in a physical (i.e. idmap with dcaches off) context. I'm not sure anyone else does that, and I'm not sure whether that's going to work (both because of the

Re: [PATCH] arm64: ignore DT memreserve entries when booting in UEFI mode

. Reported-by: Mark Rutland mark.rutl...@arm.com Signed-off-by: Leif Lindholm leif.lindh...@linaro.org --- arch/arm64/kernel/efi.c |2 ++ arch/arm64/mm/init.c|4 +++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c

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

On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel 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 not fall

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

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 will.dea...@arm.com wrote: On Wed, Jul 30, 2014 at 11:59:02AM

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

On Thu, Jul 31, 2014 at 10:45:15AM +0100, Will Deacon wrote: On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel 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

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

On Thu, Jul 31, 2014 at 11:04:39AM +0100, Will Deacon wrote: On Thu, Jul 31, 2014 at 10:58:54AM +0100, Mark Rutland wrote: On Thu, Jul 31, 2014 at 10:45:15AM +0100, Will Deacon wrote: On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote: ]On 30 July 2014 13:30, Will Deacon

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

the same for x86 as of c7fb93ec51d4 (x86/efi: Include a .bss section within the PE/COFF headers). So: Acked-by: Mark Rutland mark.rutl...@arm.com --- 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

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

still proceed normally otherwise. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Acked-by: Mark Salter msal...@redhat.com Acked-by: Mark Rutland mark.rutl...@arm.com --- arch/arm64/kernel/efi-stub.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff

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

On Wed, Aug 20, 2014 at 06:10:57PM +0100, Matt Fleming wrote: On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote: On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote: If we cannot relocate the kernel Image to its preferred offset of base of DRAM plus TEXT_OFFSET, instead

Re: [PATCH] efi/arm64: fix fdt-related memory reservation

each time we call fdt_del_mem_rsv? Shouldn't this be something like: while (fdt_num_mem_rsv(fdt)) fdt_del_mem_rsv(fdt, 0); Or we could count downwards. Otherwise, the general approach sounds sane to me, so with that bug fixed or disproven: Acked-by: Mark Rutland mark.rutl...@arm.com

Re: [PATCH] efi/arm64: fix fdt-related memory reservation

On Mon, Sep 08, 2014 at 03:21:05PM +0100, Mark Salter wrote: On Mon, 2014-09-08 at 15:06 +0100, Mark Rutland wrote: Hi Mark, On Mon, Sep 08, 2014 at 02:31:42PM +0100, Mark Salter wrote: Commit 86c8b27a01cf: arm64: ignore DT memreserve entries when booting in UEFI mode

Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings

. +microcontroller to turn the power off. This driver installs a handler +to power off the system. I'd remove the last sentence -- the driver is also independent of the HW, and the description of how the power off works at the HW level is sufficient. With that: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks

Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings

On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote: pm_power_off is an implementation detail. Replace it with a more generic description of the driver's functionality. Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com

Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings

On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote: On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. So your argument is that

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

Hi Ard, On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote: After the EFI stub has done its business, it jumps into the kernel by branching to offset #0 of the loaded Image, which is where it expects to find the header containing a 'branch to stext' instruction. However, the

Re: [PATCH] arm64/efi: set PE/COFF section alignment to 4 KB

Hi Ard, On Fri, Oct 10, 2014 at 10:25:24AM +0100, Ard Biesheuvel wrote: Position independent AArch64 code needs to be linked and loaded at the same relative offset from a 4 KB boundary, or adrp/add and adrp/ldr pairs will not work correctly. (This is how PC relative symbol references with a 4

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

On Thu, Oct 09, 2014 at 08:03:52PM +0100, Ard Biesheuvel wrote: On 9 October 2014 19:23, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote: After the EFI stub has done its business, it jumps into the kernel by branching

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

On Fri, Oct 10, 2014 at 12:52:32PM +0100, Ard Biesheuvel wrote: On 10 October 2014 12:49, Mark Rutland mark.rutl...@arm.com wrote: On Thu, Oct 09, 2014 at 08:03:52PM +0100, Ard Biesheuvel wrote: On 9 October 2014 19:23, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Wed, Oct 08

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

On Fri, Oct 10, 2014 at 02:27:46PM +0100, Ard Biesheuvel wrote: On 10 October 2014 15:03, Mark Rutland mark.rutl...@arm.com wrote: [...] But if the EFI loader is allowed to load stext at the precise start of RAM (or anywhere not in the idmap), in attempting the copy we'd try

Re: [PATCH] arm64/efi: set PE/COFF section alignment to 4 KB

On Fri, Oct 10, 2014 at 11:37:03AM +0100, Ard Biesheuvel wrote: On 10 October 2014 12:33, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Fri, Oct 10, 2014 at 10:25:24AM +0100, Ard Biesheuvel wrote: Position independent AArch64 code needs to be linked and loaded at the same relative

Re: [PATCH] arm64/efi: set PE/COFF section alignment to 4 KB

On Fri, Oct 10, 2014 at 03:50:49PM +0100, Ard Biesheuvel wrote: On 10 October 2014 16:09, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Oct 10, 2014 at 11:37:03AM +0100, Ard Biesheuvel wrote: On 10 October 2014 12:33, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Fri, Oct 10

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

describe above, and prior discussions, this looks sane to me: Acked-by: Mark Rutland mark.rutl...@arm.com Mark. --- v3: - rebased onto 3.17+ - added spec reference to commit message v2: - drop :lo12: relocation against stext_offset in favor of using a literal '=stext_offset' which

Re: [PATCH 02/10] arm64/efi: set PE/COFF section alignment to 4 KB

are emitted) We need to declare this in the PE/COFF header, otherwise the PE/COFF loader may load the Image and invoke the stub at an offset which violates this rule. Reviewed-by: Roy Franz roy.fr...@linaro.org Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Acked-by: Mark Rutland

Re: [PATCH 06/10] arm64/efi: use UEFI memory map unconditionally if available

On Wed, Oct 22, 2014 at 06:06:56PM +0100, Mark Salter wrote: On Wed, 2014-10-22 at 16:21 +0200, Ard Biesheuvel wrote: 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

Re: [PATCH 06/10] arm64/efi: use UEFI memory map unconditionally if available

attributes. If so, this patch still won't prevent that from being mapped as cacheable, but that should be easy to fix. Thanks, Mark. 8 From 581d5bac5b4a6f93e23737012b71c58d809af6bb Mon Sep 17 00:00:00 2001 From: Mark Rutland mark.rutl...@arm.com Date: Thu, 23 Oct 2014 19:41:55 +0100 Subject

Re: [PATCH v2 04/10] arm64/efi: invert UEFI memory region reservation logic

On Tue, Oct 28, 2014 at 04:18:37PM +, Ard Biesheuvel wrote: 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

Re: [PATCH v2 04/10] arm64/efi: invert UEFI memory region reservation logic

On Tue, Oct 28, 2014 at 05:08:29PM +, Ard Biesheuvel wrote: On 28 October 2014 17:47, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Oct 28, 2014 at 04:18:37PM +, Ard Biesheuvel wrote: Instead of reserving the memory regions based on which types we know need to be reserved

Re: [PATCH v2 09/10] arm64/efi: ignore unusable regions instead of reserving them

On Tue, Nov 11, 2014 at 05:12:09PM +, Mark Salter wrote: On Tue, 2014-11-11 at 10:42 -0500, Mark Salter wrote: On Mon, 2014-11-10 at 08:31 +0100, Ard Biesheuvel wrote: On 10 November 2014 05:11, Mark Salter msal...@redhat.com wrote: On Thu, 2014-11-06 at 15:13 +0100, Ard Biesheuvel

Re: [PATCH v2 09/10] arm64/efi: ignore unusable regions instead of reserving them

On Tue, Nov 11, 2014 at 05:55:24PM +, Ard Biesheuvel wrote: On 11 November 2014 18:44, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Nov 11, 2014 at 05:12:09PM +, Mark Salter wrote: On Tue, 2014-11-11 at 10:42 -0500, Mark Salter wrote: On Mon, 2014-11-10 at 08:31 +0100, Ard

Re: [PATCH] arm64/efi: handle potential failure to remap memory map

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.biesheu...@linaro.org Acked-by: Mark Rutland mark.rutl...@arm.com This should probably be picked up

Re: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors

On Thu, Feb 12, 2015 at 05:24:19AM +, Ard Biesheuvel wrote: As it turns out, when allocating room for the UEFI memory map using UEFI's AllocatePool (), it may result in two new memory map entries being created, for instance, when using Tianocore's preallocated region feature. For example,

Re: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors

On Thu, Feb 12, 2015 at 10:39:46AM +, Ard Biesheuvel wrote: On 12 February 2015 at 18:22, Mark Rutland mark.rutl...@arm.com wrote: On Thu, Feb 12, 2015 at 05:24:19AM +, Ard Biesheuvel wrote: As it turns out, when allocating room for the UEFI memory map using UEFI's AllocatePool

Re: [PATCH v4 6/8] arm64/efi: move SetVirtualAddressMap() to UEFI stub

Hi Ard, I have a few (minor) comments below. On Mon, Dec 22, 2014 at 10:59:02AM +, Ard Biesheuvel wrote: 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

Re: [PATCH] efi: stub: call get_memory_map() to obtain map and desc sizes

On Thu, Jan 08, 2015 at 07:09:22PM +, Ard Biesheuvel wrote: On 8 January 2015 at 19:04, Mark Rutland mark.rutl...@arm.com wrote: Hi Ard, On Thu, Jan 08, 2015 at 05:51:47PM +, Ard Biesheuvel wrote: This fixes two minor issues in the implementation of get_memory_map(): - Currently

Re: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors

: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. --- From 3f281b98ffc99e604a3988aa93304a3a591eeeb5 Mon Sep 17 00:00:00 2001 From: Matt Fleming matt.flem...@intel.com Date: Fri, 13 Feb 2015 15:46:56 + Subject: [PATCH] Revert efi/libstub: Call get_memory_map() to obtain map

Re: [PATCH] efi: get_memory_map: add sufficient slack for memory descriptors

On Thu, Feb 12, 2015 at 02:56:51PM +, Ard Biesheuvel wrote: On 12 February 2015 at 22:47, Matt Fleming m...@codeblueprint.co.uk wrote: On Thu, 12 Feb, at 06:39:46PM, Ard Biesheuvel wrote: I don't see how doing a single allocation could result in a single free region to be split into

Re: [PATCH] arm64/efi: use UEFI ResetSystem() Runtime Service for system reset

(EFI_RUNTIME_SERVICES); } I've given the patch a spin (with and without that addition) on Juno and Seattle. So with that folded in: Tested-by: Mark Rutland mark.rutl...@arm.com Reviewed-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH] efi: fix boundary checking in efi_high_alloc()

would expect. - Matt ] Signed-off-by: Yinghai Lu ying...@kernel.org Cc: sta...@vger.kernel.org I've convinced myself that the new logic is sound, and with this patch applied atop of v4.0-rc1 I don't see regressions on the platforms I have access to. So: Reviewed-by: Mark Rutland mark.rutl

Re: [PATCH v2] arm64/efi: prefer AllocatePages() over efi_low_alloc() for vmlinux

to allocate at the base of DRAM if DRAM starts at 0x0, since efi_low_alloc() refuses to allocate at 0x0. Tested-by: Haojian Zhuang haojian.zhu...@linaro.org Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Reviewed-by: Mark Rutland mark.rutl...@arm.com Mark. --- v2: - reshuffle code flow

Re: [PATCH] arm64/efi: prefer AllocatePages() over efi_low_alloc() for vmlinux

Hi Ard, On Fri, Jul 24, 2015 at 10:41:53AM +0100, Ard Biesheuvel wrote: When allocating memory for the kernel image, try the AllocatePages() boot service to obtain memory at the preferred offset of 'dram_base + TEXT_OFFSET', and only revert to efi_low_alloc() if that fails. This is the only

Re: [PATCH] arm64: efi: make sure vmlinux load address aligned on 2MBytes

On Tue, Oct 27, 2015 at 09:13:22PM -0500, Timur Tabi wrote: > Ard Biesheuvel wrote: > >No. I screwed up the patch since the trailing ) should not be there, > >but we do need to round first, and only then add the offset. > > But if the offset is not a multiple of 2MB, won't the address passed > to

Re: [PATCH] [v2] arm64: efi: make sure vmlinux load address aligned on 2MB

On Thu, Oct 29, 2015 at 11:59:46AM +0900, Ard Biesheuvel wrote: > On 29 October 2015 at 03:21, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Wed, Oct 28, 2015 at 01:12:36PM -0500, Timur Tabi wrote: > >> On 10/28/2015 01:08 PM, Mark Rutland wrote: > >> > >

Re: [PATCH] arm64: efi: make sure vmlinux load address aligned on 2MBytes

EFI_PAGE_SIZE; > > status = efi_call_early(allocate_pages, > > EFI_ALLOCATE_ADDRESS, > > Tested-by: Timur Tabi <ti...@codeaurora.org> > Tested-by: Shanker Donthineni <shank...@codeaurora.org> I assume with the trailing ')' remo

Re: [PATCH] [v2] arm64: efi: make sure vmlinux load address aligned on 2MB

On Wed, Oct 28, 2015 at 01:12:36PM -0500, Timur Tabi wrote: > On 10/28/2015 01:08 PM, Mark Rutland wrote: > > >arm64: efi: ensure kernel is loaded at correct address > > > >The kernel image needs to be loaded text_offset_bytes from a 2M-aligned > >base, per D

Re: [PATCH] arm64: efi: make sure vmlinux load address aligned on 2MBytes

On Wed, Oct 28, 2015 at 04:02:23PM -0500, Timur Tabi wrote: > On 10/28/2015 12:26 PM, Mark Rutland wrote: > >>>This does make the kernel boot, but we suspect that there may be > >>>another problem. We need to investigate it, but we have a suspicion > >>>

Re: [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote: > On 17 November 2015 at 10:57, wrote: > > From: Shannon Zhao > > > > Add a new function to parse DT parameters for Xen specific UEFI just > > like the way for normal UEFI. Then it

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Adding Catalin to the To line] On Fri, Oct 30, 2015 at 01:17:24PM +0100, Ard Biesheuvel wrote: > On 27 October 2015 at 23:44, Jeremy Linton wrote: > > On 10/26/2015 09:20 PM, Ard Biesheuvel wrote: > >> > >> Thanks for the report. The following patch should fix it > > > >

Re: [PATCH v6 0/6] KASAN for arm64

On Thu, Oct 08, 2015 at 01:36:09PM +0300, Andrey Ryabinin wrote: > 2015-10-07 13:04 GMT+03:00 Catalin Marinas : > > On Thu, Sep 17, 2015 at 12:38:06PM +0300, Andrey Ryabinin wrote: > >> As usual patches available in git > >> git://github.com/aryabinin/linux.git

Re: [PATCH v6 0/6] KASAN for arm64

On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote: [...] > I thought the EFI stub isolation patches create a copy of mem*() functions in > the stub, > but they are just create aliases with __efistub_ prefix. > > We only need to create some more aliases for KASAN. > The following

Re: [PATCH v6 0/6] KASAN for arm64

On Fri, Oct 09, 2015 at 01:18:09PM +0300, Andrey Ryabinin wrote: > 2015-10-09 12:48 GMT+03:00 Mark Rutland <mark.rutl...@arm.com>: > > On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote: > > [...] > > > >> I thought the EFI stub isolation patch

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

Hi, I'm not necessarily opposed to the renaming, but I think that this is the least important thing to standardize for this to work. On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote: > From: Shannon Zhao > > These EFI stub parameters are used to internal

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > interface? > > > > > > Xen talks to EFI itself b

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > interface? > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > different: there are no BootServices (Xen calls ExitBootServices before > running the kernel), and the RuntimeServices go via

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

Hi, FWIW I gave this a spin on Seattle and Juno and saw no regressions (both are pre-2.5 EFI though). I have some concerns below. On Wed, Sep 09, 2015 at 08:06:54AM +0100, Ard Biesheuvel wrote: > The new Properties Table feature introduced in UEFIv2.5 may split > memory regions that cover

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > >> index e8ca6eaedd02..13671a9cf016 100644 > >> --- a/arch/arm64/kernel/efi.c > >> +++ b/arch/arm64/kernel/efi.c > >> @@ -258,7 +258,8 @@ static bool __init efi_virtmap_init(void) > >>*/ > >> if

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > Does Xen not talk

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: > >>> On 10.09.15 at 13:37, <stefano.stabell...@eu.citrix.com> wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > &g

Re: [PATCH v2] arm64/efi: don't pad between EFI_MEMORY_RUNTIME regions

> OK so what we could do is the following: > > 8<-- > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c > index e8ca6eaedd02..39fa2a70a7f1 100644 > --- a/arch/arm64/kernel/efi.c > +++ b/arch/arm64/kernel/efi.c > @@ -233,6 +233,7 @@ void __init efi_init(void) >

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> > C) When you could go: > > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI > > discovery > > I take you mean discovering Xen with the usual Xen hypervisor node on > device tree. I think that C) is a good option actually. I like it. Not > sure why we didn't think

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> >> Considering that the EFI support is just for Dom0, and Dom0 (at > >> the time) had to be PV anyway, it was the more natural solution to > >> expose the interface via hypercalls, the more that this allows better > >> control over what is and primarily what is not being exposed to > >> Dom0.

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> It feels like this discussion is going in circles. > > When we discussed this six months ago, we already concluded that, > since UEFI is the only specified way that the presence of ACPI is > advertised on an ARM system, we need to emulate UEFI to some extent. My understanding from the last

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > >

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > > C) When you could go: > > > > > > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACP

Re: [PATCH 3/4] efi/libstub: arm/arm64: disable debug prints on 'quiet' cmdline arg

ned-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > This was previously sent out as a separate patch. The difference is that this > version looks for 'quiet' rather than 'efi=debug', and preserves the noisy > console as the default. This addresses my prior concern, so F

Re: [PATCH] efi/libstub: arm/arm64: make debug prints dependent on efi=debug

On Mon, Mar 20, 2017 at 08:57:05PM +, Ard Biesheuvel wrote: > The EFI stub currently prints a number of diagnostic messages that do > not carry a lot of information. Since these prints are not controlled > by 'loglevel' or other command line parameters, and since they appear on > the EFI

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

[Adding the EFI maintainers] Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when invoked on arm64 we get a NULL dereference. On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen

Re: [PATCH] efi/libstub: arm/arm64: don't use TASK_SIZE when randomising the RT space

TASK_SIZE on ARM, both of which > are compile time constants. Also, change the 'headroom' variable to > static const to force an error if this changes in the future. > > Cc: James Morse <james.mo...@arm.com> > Cc: Mark Rutland <mark.rutl...@arm.com> > Cc: Catalin Marina

Re: [PATCH 4/4] ef/libstub: arm/arm64: randomize the base of the UEFI rt services region

On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote: > On 7 April 2017 at 16:47, James Morse wrote: > > On 24/03/17 13:24, Ard Biesheuvel wrote: > >> Update the allocation logic for the virtual mapping of the UEFI runtime > >> services to start from a randomized

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Wed, Aug 16, 2017 at 10:31:12AM +0100, Ard Biesheuvel wrote: > (+ Mark, Will) > > On 15 August 2017 at 22:46, Andy Lutomirski wrote: > > On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya > > wrote: > >> +/* > >> + * Makes the calling

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Wed, Aug 16, 2017 at 11:07:10AM +0100, Will Deacon wrote: > On Wed, Aug 16, 2017 at 10:53:38AM +0100, Mark Rutland wrote: > > On Wed, Aug 16, 2017 at 10:31:12AM +0100, Ard Biesheuvel wrote: > > > (+ Mark, Will) > > > > > > On 15 August 2017 at 22:46, And

Re: [PATCH] efi: arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP

d > memblock_reserve() them instead of marking them MEMBLOCK_NOMAP. > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> Sounds sane to me. FWIW: Acked-by: Mark Rutland <mark.rutl...@arm.com> Thanks, Mark. > --- > drivers/firmware/efi/arm-init.c | 5 + > 1

Re: [PATCH v4 19/27] x86: assembly, make some functions local

Hi Jiri, I can see that these serve a useful purpose (as they are necessary for asm validation encessary for livepatching), and I am not personally averse to the new annotations. However, I am concerned that as-is, this is going to create more problems for !x86 architectures. More on that below.

Re: [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041

Hi, On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote: > +/** > + * Errata workaround prior to disable MMU. Insert an ISB immediately prior > + * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0. > + */ > + .macro pre_disable_mmu_workaround > +#ifdef

Re: [PATCH v4 19/27] x86: assembly, make some functions local

On Wed, Oct 25, 2017 at 04:21:48PM +0200, Jiri Slaby wrote: > Hi, > > On 10/06/2017, 03:21 PM, Mark Rutland wrote: > > If the aim of this series is to introduce something that architectures > > use consistently, then can we please actually poke other architectures &g

[PATCH] efi/arm*: Only register page tables when they exist

: 91400420 f90033a0 a90707a2 f9403fa0 (f940) [ 479.531499] ---[ end trace bfe8e28d8acb2b67 ]--- Segmentation fault Let's avoid this problem by only registering the tables after their successful creation, which is also less confusing when EFI runtime services are not in use. Signed-off-by: Mark Rutland

Re: [PATCH V2 2/3] efi: Introduce efi_rts_workqueue and some infrastructure to invoke all efi_runtime_services()

On Mon, Mar 05, 2018 at 03:23:09PM -0800, Sai Praneeth Prakhya wrote: > @@ -329,6 +331,19 @@ static int __init efisubsys_init(void) > return 0; > > /* > + * Since we process only one efi_runtime_service() at a time, an > + * ordered workqueue (which creates only one

Re: [PATCH V2 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services

. or do we assume that since something has already gone wrong, this doesn't matter? Otherwise, this doesn't seem to break basic stuff on arm64 platforms. I can boot up, read the EFI RTC, and reboot. I ahd lockdep and KASAN enabled, I received no splats from either. FWIW: Tested-by: Mark Rutlan

Re: [PATCH] efi/libstub/arm64: handle randomized TEXT_OFFSET

On Tue, Apr 24, 2018 at 01:11:40PM +0200, Ard Biesheuvel wrote: > Hi Mark, > > On 24 April 2018 at 13:00, Mark Rutland <mark.rutl...@arm.com> wrote: > > When CONFIG_RANDOMIZE_TEXT_OFFSET is selected, TEXT_OFFSET is an > > arbitrary multiple of PAGE_SIZE in the interva

Re: [PATCH v8 2/5] arm64: replace -pg with CC_FLAGS_FTRACE in efi Makefiles

rm32 as well. > > There should be no functional change as a result of this patch. > > Signed-off-by: Torsten Duwe With the indentation removed from the commit text: Reviewed-by: Mark Rutland Mark. > > --- > drivers/firmware/efi/libstub/Makefile |6 +++--- >

Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK

On Thu, Aug 15, 2019 at 02:21:26PM +0300, Ard Biesheuvel wrote: > On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote: > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > > > Hi, > > > > > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm6

Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK

On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > Hi, > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64 > macchiatobin board and I get the following error when loading the > kernel (using grub-efi on top of edk ii): > > EFI stub: Booting Linux Kernel... > EFI stub:

Re: [PATCH v8 2/5] arm64: replace -pg with CC_FLAGS_FTRACE in efi Makefiles

On Fri, Feb 08, 2019 at 04:10:11PM +0100, Torsten Duwe wrote: > In preparation for arm64 supporting ftrace built on other compiler > options, let's have makefiles remove the $(CC_FLAGS_FTRACE) > flags, whatever these may be, rather than assuming '-pg'. > While at it, fix arm32 as well. >