From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] arm64/efi: ensure that Image does not cross a 512 MB boundary
Date: Wed, 11 Mar 2015 11:50:28 +0000 [thread overview]
Message-ID: <20150311115028.GD4114@leverpostej> (raw)
In-Reply-To: <1425380630-3684-5-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On Tue, Mar 03, 2015 at 11:03:49AM +0000, Ard Biesheuvel wrote:
> Update the Image placement logic used by the stub to make absolutely
> sure that Image is placed in such a way that the early init code will
Minor grammatical nits:
s/that Image/that the Image/
s/in such a way that/such that/
> always be able to map it. This means the entire static memory footprint
> of Image should be inside the same naturally aligned 512 MB region.
s/Image/the Image/
>
> First of all, the preferred offset of dram_base + TEXT_OFFSET is only
> suitable if it doesn't result in the Image crossing a 512 MB
> alignment boundary, which could be the case if dram_base itself
> is close to the end of a naturally aligned 512 MB region.
>
> Also, when moving the kernel Image, we need to verify that the new
> destination region does not cross a 512 MB alignment boundary either.
> If that is the case, we retry the allocation with the alignment
> chosen such that the resulting region will always be suitable.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/efi-stub.c | 38 ++++++++++++++++++++++++++++++++------
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
> index f5374065ad53..5f8175979be8 100644
> --- a/arch/arm64/kernel/efi-stub.c
> +++ b/arch/arm64/kernel/efi-stub.c
> @@ -22,14 +22,40 @@ efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table,
> efi_loaded_image_t *image)
> {
> efi_status_t status;
> - unsigned long kernel_size, kernel_memsize = 0;
> + unsigned long kernel_size, kernel_memsize;
> + unsigned long preferred_offset;
>
> - /* Relocate the image, if required. */
> kernel_size = _edata - _text;
> - if (*image_addr != (dram_base + TEXT_OFFSET)) {
> - kernel_memsize = kernel_size + (_end - _edata);
> - status = efi_low_alloc(sys_table, kernel_memsize + TEXT_OFFSET,
> - SZ_2M, reserve_addr);
> + kernel_memsize = kernel_size + (_end - _edata);
> +
> + /*
> + * The kernel Image should be located as close as possible to the base
> + * of system RAM, but must not cross a 512 MB alignment boundary.
It might be better to say "but its static memory footprint must not
cross a 512MB boundary" or something to that effect, to avoid any
ambiguity regarding the Image binary vs the runtime memory footprint
thereof.
> + */
> + preferred_offset = dram_base + TEXT_OFFSET;
> + if ((preferred_offset & (SZ_512M - 1)) + kernel_memsize > SZ_512M)
> + preferred_offset = round_up(dram_base, SZ_512M) + TEXT_OFFSET;
> +
> + if (*image_addr != preferred_offset) {
> + unsigned long alloc_size = kernel_memsize + TEXT_OFFSET;
This could be const.
> + unsigned long alloc_align = SZ_2M;
> +
> +again:
> + status = efi_low_alloc(sys_table, alloc_size, alloc_align,
> + reserve_addr);
> +
> + /*
> + * Check whether the new allocation crosses a 512 MB alignment
> + * boundary. If so, retry with the alignment set to a power of
> + * two upper bound of the allocation size. That is guaranteed
> + * to produce a suitable allocation, but may waste more memory.
> + */
> + if (status == EFI_SUCCESS &&
> + ((*reserve_addr & (SZ_512M - 1)) + alloc_size) > SZ_512M) {
> + efi_free(sys_table, alloc_size, *reserve_addr);
> + alloc_align = roundup_pow_of_two(alloc_size);
> + goto again;
> + }
If you move this check after the status != EFI_SUCCESS check below then
you don't need to check status == EFI_SUCCESS, which would make the
condition a little more legible.
Other than those comments this looks sane to me.
Thanks,
Mark.
> if (status != EFI_SUCCESS) {
> pr_efi_err(sys_table, "Failed to relocate kernel\n");
> return status;
> --
> 1.8.3.2
>
>
next prev parent reply other threads:[~2015-03-11 11:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 11:03 [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 1/5] of/fdt: allow FDT virtual address outside of linear direct mapping Ard Biesheuvel
2015-03-10 21:47 ` Rob Herring
2015-03-11 8:34 ` Ard Biesheuvel
2015-03-11 11:48 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 2/5] arm64: use fixmap region for permanent FDT mapping Ard Biesheuvel
2015-03-10 21:37 ` Rob Herring
2015-03-11 7:05 ` Ard Biesheuvel
2015-03-11 9:50 ` Mark Rutland
2015-03-11 10:20 ` Ard Biesheuvel
2015-03-11 10:46 ` Mark Rutland
2015-03-11 12:22 ` Rob Herring
2015-03-11 10:43 ` Mark Rutland
2015-03-11 10:54 ` Ard Biesheuvel
2015-03-11 11:56 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 3/5] arm64: Documentation: clarify Image placement in physical RAM Ard Biesheuvel
2015-03-11 10:04 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 4/5] arm64/efi: ensure that Image does not cross a 512 MB boundary Ard Biesheuvel
2015-03-11 11:50 ` Mark Rutland [this message]
2015-03-11 15:00 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 5/5] arm64/efi: adapt to relaxed FDT placement requirements Ard Biesheuvel
2015-03-11 12:09 ` Mark Rutland
2015-03-11 14:42 ` Ard Biesheuvel
2015-03-10 10:51 ` [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-10 11:21 ` Mark Rutland
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=20150311115028.GD4114@leverpostej \
--to=mark.rutland@arm.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).