linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jeffy.chen@rock-chips.com (jeffy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
Date: Mon, 23 Oct 2017 11:28:00 +0800	[thread overview]
Message-ID: <59ED61C0.50602@rock-chips.com> (raw)
In-Reply-To: <20171022141457.28769-1-ard.biesheuvel@linaro.org>

Hi Ard,

this patch fixes the zImage file size not aligned issue i meet, thanks:)

Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>

On 10/22/2017 10:14 PM, Ard Biesheuvel wrote:
> ARM shares its EFI stub implementation with arm64, which has some
> special handling in the virtual remapping code to
> a) make sure that we can map everything even if the OS executes
>     with 64k page size, and
> b) make sure that adjacent regions with the same attributes are not
>     reordered or moved apart in memory.
>
> The latter is a workaround for a 'feature' that was shortly recommended
> by UEFI spec v2.5, but deprecated shortly after, due to the fact that
> it broke many OS installers, including non-Linux ones, and it was never
> widely implemented for ARM systems. Before implementing b), the arm64
> code simply rounded up all regions to 64 KB granularity, but given that
> that results in moving adjacent regions apart, it had to be refined when
> b) was implemented.
>
> The adjacency check requires a sort() pass, due to the fact that the
> UEFI spec does not mandate any ordering, and the inclusion of the
> lib/sort.c code into the ARM EFI stub is causing some trouble with
> the decompressor build due to the fact that its EXPORT_SYMBOL() call
> triggers the creation of ksymtab/kcrctab sections.
>
> So let's simply do away with the adjacency check for ARM, and simply put
> all UEFI runtime regions together if they have the same memory attributes.
> This is guaranteed to work, given that ARM only supports 4 KB pages,
> and allows us to remove the sort() call entirely.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>   drivers/firmware/efi/libstub/Makefile   | 6 +++---
>   drivers/firmware/efi/libstub/arm-stub.c | 7 +++++--
>   2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index dedf9bde44db..f3e8431565ea 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -33,13 +33,14 @@ lib-y				:= efi-stub-helper.o gop.o secureboot.o
>   lib-$(CONFIG_RESET_ATTACK_MITIGATION) += tpm.o
>
>   # include the stub's generic dependencies from lib/ when building for ARM/arm64
> -arm-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c sort.c
> +arm-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
> +arm-deps-$(CONFIG_ARM64) += sort.c
>
>   $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
>   	$(call if_changed_rule,cc_o_c)
>
>   lib-$(CONFIG_EFI_ARMSTUB)	+= arm-stub.o fdt.o string.o random.o \
> -				   $(patsubst %.c,lib-%.o,$(arm-deps))
> +				   $(patsubst %.c,lib-%.o,$(arm-deps-y))
>
>   lib-$(CONFIG_ARM)		+= arm32-stub.o
>   lib-$(CONFIG_ARM64)		+= arm64-stub.o
> @@ -90,5 +91,4 @@ quiet_cmd_stubcopy = STUBCPY $@
>   # explicitly by the decompressor linker script.
>   #
>   STUBCOPY_FLAGS-$(CONFIG_ARM)	+= --rename-section .data=.data.efistub
> -STUBCOPY_RM-$(CONFIG_ARM)	+= -R ___ksymtab+sort -R ___kcrctab+sort
>   STUBCOPY_RELOC-$(CONFIG_ARM)	:= R_ARM_ABS
> diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
> index 1cb2d1c070c3..3061e4057483 100644
> --- a/drivers/firmware/efi/libstub/arm-stub.c
> +++ b/drivers/firmware/efi/libstub/arm-stub.c
> @@ -349,7 +349,9 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
>   	 * The easiest way to find adjacent regions is to sort the memory map
>   	 * before traversing it.
>   	 */
> -	sort(memory_map, map_size / desc_size, desc_size, cmp_mem_desc, NULL);
> +	if (IS_ENABLED(CONFIG_ARM64))
> +		sort(memory_map, map_size / desc_size, desc_size, cmp_mem_desc,
> +		     NULL);
>
>   	for (l = 0; l < map_size; l += desc_size, prev = in) {
>   		u64 paddr, size;
> @@ -366,7 +368,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
>   		 * a 4k page size kernel to kexec a 64k page size kernel and
>   		 * vice versa.
>   		 */
> -		if (!regions_are_adjacent(prev, in) ||
> +		if ((IS_ENABLED(CONFIG_ARM64) &&
> +		     !regions_are_adjacent(prev, in)) ||
>   		    !regions_have_compatible_memory_type_attrs(prev, in)) {
>
>   			paddr = round_down(in->phys_addr, SZ_64K);
>

  reply	other threads:[~2017-10-23  3:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-22 14:14 [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map Ard Biesheuvel
2017-10-23  3:28 ` jeffy [this message]
2017-10-23 21:08 ` Matthias Brugger
2017-10-24 11:05 ` Russell King - ARM Linux
2017-10-24 11:09   ` Ard Biesheuvel
2017-10-24 11:21     ` Will Deacon
2017-10-27 14:41 ` Gregory CLEMENT
2017-10-27 15:12 ` Matthias Brugger
2017-10-27 15:28   ` Russell King - ARM Linux
2017-10-27 16:29     ` Matthias Brugger
2017-10-27 16:30     ` Matthias Brugger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59ED61C0.50602@rock-chips.com \
    --to=jeffy.chen@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).