From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Leif Lindholm <leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Roy Franz <roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>, Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>, Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Subject: Re: [PATCH 1/8] arm64/efi: use UEFI memory map unconditionally if available Date: Wed, 7 Jan 2015 11:48:51 +0000 [thread overview] Message-ID: <CAKv+Gu_q5wFhjb8M7VptVtHfm5vfp6_YiqN_XoTs9qV5=8OOdg@mail.gmail.com> (raw) In-Reply-To: <20150106090407.GF3163-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> On 6 January 2015 at 09:04, Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> wrote: > On Mon, 22 Dec, at 07:08:35PM, 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 is handled by reserve_regions, which not only >> reserves parts of memory that UEFI declares as reserved, but also installs >> the memblocks that cover the remaining usable memory. >> >> Currently, reserve_regions() is only called if uefi_init() succeeds. >> However, it does not actually depend on anything that uefi_init() does, >> and not calling reserve_regions() results in a broken boot, so it is >> better to just call it unconditionally. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> >> --- >> arch/arm64/kernel/efi.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c >> index d7d2e818c856..d2f483a7cffe 100644 >> --- a/arch/arm64/kernel/efi.c >> +++ b/arch/arm64/kernel/efi.c >> @@ -208,8 +208,7 @@ void __init efi_init(void) >> memmap.desc_size = params.desc_size; >> memmap.desc_version = params.desc_ver; >> >> - if (uefi_init() < 0) >> - return; >> + WARN_ON(uefi_init() < 0); >> >> reserve_regions(); >> } >> @@ -218,15 +217,13 @@ static int __init arm64_enter_virtual_mode(void) >> { >> u64 mapsize; >> >> - if (!efi_enabled(EFI_BOOT)) { >> - pr_info("EFI services will not be available.\n"); >> - return -1; >> - } >> + if (!efi_enabled(EFI_MEMMAP)) >> + return 0; >> >> mapsize = memmap.map_end - memmap.map; >> early_memunmap(memmap.map, mapsize); >> >> - if (efi_runtime_disabled()) { >> + if (!efi_enabled(EFI_BOOT) || efi_runtime_disabled()) { >> pr_info("EFI runtime services will be disabled.\n"); >> return -1; >> } > > Am I correct in thinking that it's possible to have EFI_MEMMAP set but > not EFI_BOOT? That's not how things work on x86. EFI_BOOT means "I am an > EFI-enabled platform and I was booted using EFI." > > In other words, EFI_MEMMAP should imply EFI_BOOT (how did you get the > memmap if you weren't booted using EFI?) > In the arm64 case, the memory map is retrieved by the stub, and its address is passed via the /chosen DT node, which also contains the address of the EFI system table. In the unlikely event that, for instance, the FEI system table signature is corrupted, we will not set EFI_BOOT (nor EFI_64BIT). > It looks like you should be setting EFI_BOOT (and EFI_64BIT) in > efi_init() if efi_get_fdt_params() succeeds. > Yes, I agree. We should probably set EFI_SYSTEM_TABLES in uefi_init() then, and possibly unset it again if we fail to remap it. -- Ard.
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/8] arm64/efi: use UEFI memory map unconditionally if available Date: Wed, 7 Jan 2015 11:48:51 +0000 [thread overview] Message-ID: <CAKv+Gu_q5wFhjb8M7VptVtHfm5vfp6_YiqN_XoTs9qV5=8OOdg@mail.gmail.com> (raw) In-Reply-To: <20150106090407.GF3163@console-pimps.org> On 6 January 2015 at 09:04, Matt Fleming <matt@console-pimps.org> wrote: > On Mon, 22 Dec, at 07:08:35PM, 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 is handled by reserve_regions, which not only >> reserves parts of memory that UEFI declares as reserved, but also installs >> the memblocks that cover the remaining usable memory. >> >> Currently, reserve_regions() is only called if uefi_init() succeeds. >> However, it does not actually depend on anything that uefi_init() does, >> and not calling reserve_regions() results in a broken boot, so it is >> better to just call it unconditionally. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> --- >> arch/arm64/kernel/efi.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c >> index d7d2e818c856..d2f483a7cffe 100644 >> --- a/arch/arm64/kernel/efi.c >> +++ b/arch/arm64/kernel/efi.c >> @@ -208,8 +208,7 @@ void __init efi_init(void) >> memmap.desc_size = params.desc_size; >> memmap.desc_version = params.desc_ver; >> >> - if (uefi_init() < 0) >> - return; >> + WARN_ON(uefi_init() < 0); >> >> reserve_regions(); >> } >> @@ -218,15 +217,13 @@ static int __init arm64_enter_virtual_mode(void) >> { >> u64 mapsize; >> >> - if (!efi_enabled(EFI_BOOT)) { >> - pr_info("EFI services will not be available.\n"); >> - return -1; >> - } >> + if (!efi_enabled(EFI_MEMMAP)) >> + return 0; >> >> mapsize = memmap.map_end - memmap.map; >> early_memunmap(memmap.map, mapsize); >> >> - if (efi_runtime_disabled()) { >> + if (!efi_enabled(EFI_BOOT) || efi_runtime_disabled()) { >> pr_info("EFI runtime services will be disabled.\n"); >> return -1; >> } > > Am I correct in thinking that it's possible to have EFI_MEMMAP set but > not EFI_BOOT? That's not how things work on x86. EFI_BOOT means "I am an > EFI-enabled platform and I was booted using EFI." > > In other words, EFI_MEMMAP should imply EFI_BOOT (how did you get the > memmap if you weren't booted using EFI?) > In the arm64 case, the memory map is retrieved by the stub, and its address is passed via the /chosen DT node, which also contains the address of the EFI system table. In the unlikely event that, for instance, the FEI system table signature is corrupted, we will not set EFI_BOOT (nor EFI_64BIT). > It looks like you should be setting EFI_BOOT (and EFI_64BIT) in > efi_init() if efi_get_fdt_params() succeeds. > Yes, I agree. We should probably set EFI_SYSTEM_TABLES in uefi_init() then, and possibly unset it again if we fail to remap it. -- Ard.
next prev parent reply other threads:[~2015-01-07 11:48 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-22 19:08 [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel [not found] ` <1419275322-29811-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2014-12-22 19:08 ` [PATCH 1/8] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel [not found] ` <1419275322-29811-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-01-06 9:04 ` Matt Fleming 2015-01-06 9:04 ` Matt Fleming [not found] ` <20150106090407.GF3163-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> 2015-01-07 11:48 ` Ard Biesheuvel [this message] 2015-01-07 11:48 ` Ard Biesheuvel [not found] ` <CAKv+Gu_q5wFhjb8M7VptVtHfm5vfp6_YiqN_XoTs9qV5=8OOdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-12 10:46 ` Matt Fleming 2015-01-12 10:46 ` Matt Fleming 2015-01-09 15:41 ` Will Deacon 2015-01-09 15:41 ` Will Deacon 2014-12-22 19:08 ` [PATCH 2/8] arm64/efi: register UEFI reserved regions as iomem resources Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel [not found] ` <1419275322-29811-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-01-06 9:13 ` Matt Fleming 2015-01-06 9:13 ` Matt Fleming [not found] ` <20150106091322.GG3163-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> 2015-01-07 11:53 ` Ard Biesheuvel 2015-01-07 11:53 ` Ard Biesheuvel 2014-12-22 19:08 ` [PATCH 3/8] memblock: add physmem to memblock_dump_all() output Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel 2015-01-06 9:15 ` Matt Fleming 2015-01-06 9:15 ` Matt Fleming 2015-01-06 9:15 ` Matt Fleming 2014-12-22 19:08 ` [PATCH 4/8] memblock: introduce memblock_add_phys() and memblock_is_physmem() Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel 2015-01-06 9:19 ` Matt Fleming 2015-01-06 9:19 ` Matt Fleming 2015-01-06 9:19 ` Matt Fleming 2014-12-22 19:08 ` [PATCH 5/8] of: fdt: register physmem in early_init_dt_scan_memory() Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel 2014-12-22 19:08 ` [PATCH 6/8] arm64/efi: register physmem in reserve_regions() Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel 2014-12-22 19:08 ` [PATCH 7/8] arm64: use 'physmem' memblock to improve CONFIG_STRICT_DEVMEM handling Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel [not found] ` <1419275322-29811-8-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-01-09 15:38 ` Will Deacon 2015-01-09 15:38 ` Will Deacon 2014-12-22 19:08 ` [PATCH 8/8] arm64/efi: memblock_remove rather than _reserve UEFI reserved RAM Ard Biesheuvel 2014-12-22 19:08 ` Ard Biesheuvel 2014-12-26 9:35 ` [PATCH 0/8] arm64: improved memory map handling for /dev/mem, ACPI etc Dave Young 2014-12-26 9:35 ` Dave Young [not found] ` <20141226093528.GA26133-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org> 2014-12-29 9:22 ` Ard Biesheuvel 2014-12-29 9:22 ` Ard Biesheuvel [not found] ` <CAKv+Gu_1VCJK7y5U9H-mhjjN6AFW8+SGvbKUZfuzx6qGEpVg0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-12-30 9:25 ` Dave Young 2014-12-30 9:25 ` Dave Young [not found] ` <20141230092514.GF2457-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org> 2014-12-30 13:21 ` Ard Biesheuvel 2014-12-30 13:21 ` Ard Biesheuvel [not found] ` <CAKv+Gu_Ou6Fv7-AUcpbUJAijwEJ8=PCB1mQU3mCfctLFAMhu_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-04 8:19 ` Dave Young 2015-01-04 8:19 ` Dave Young [not found] ` <20150104081905.GA6231-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org> 2015-01-05 9:18 ` Ard Biesheuvel 2015-01-05 9:18 ` Ard Biesheuvel [not found] ` <CAKv+Gu-P7AeMNveZMe814FgrEr_z26vaYKWa=borKoPSc76Y6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-06 8:16 ` Dave Young 2015-01-06 8:16 ` Dave Young [not found] ` <20150106081635.GE2113-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org> 2015-01-07 11:41 ` Ard Biesheuvel 2015-01-07 11:41 ` Ard Biesheuvel [not found] ` <CAKv+Gu9DQLZnvNyF0qdk5jSH6=NvdsKYTX+E46U=kGRzCEfwHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-01-08 1:29 ` Dave Young 2015-01-08 1:29 ` Dave Young
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='CAKv+Gu_q5wFhjb8M7VptVtHfm5vfp6_YiqN_XoTs9qV5=8OOdg@mail.gmail.com' \ --to=ard.biesheuvel-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \ --cc=bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org \ --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \ --cc=dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org \ --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.