All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.