linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 06/10] arm64/efi: use UEFI memory map unconditionally if available
Date: Thu, 23 Oct 2014 12:19:58 -0400	[thread overview]
Message-ID: <1414081198.6829.12.camel@deneb.redhat.com> (raw)
In-Reply-To: <20141023155428.GA977@leverpostej>

On Thu, 2014-10-23 at 16:54 +0100, Mark Rutland wrote:
> 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 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 51522ab0c6da..4cec21b1ecdd 100644
> > > --- a/arch/arm64/kernel/efi.c
> > > +++ b/arch/arm64/kernel/efi.c
> > > @@ -313,8 +313,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();
> > >  }
> > 
> > It also looks like EFI_BOOT flag will be set even if uefi_init fails.
> > If uefi_init fails, we only need reserve_regions() for the purpose
> > of adding memblocks. Otherwise, we end up wasting a lot of memory.
> 
> What memory are we wasting in that case? Surely the only items that we
> could choose to throw away if we failed uefi_init are
> EFI_ACPI_RECLAIM_MEMORY and EFI_MEMORY_RUNTIME?
> 
> We might want to keep those around so we can kexec into a kernel where
> we can make use of them. Surely they shouldn't take up a significant
> proportion of the available memory?

In addition, reserve_regions() also reserves BOOT_SERVICES (which gets
freed up later after set_virtual_address_map(). That won't happen if
uefi_init() fails. In any case, if uefi_init() fails, we won't be able
to find the ACPI tables kexec kernel won't be able to either. The
BOOT_SERVICES stuff is the big chunk. There was some discussion of
not reserving that but no one has gotten around to writing the patch
to clean out the code that does it.

  reply	other threads:[~2014-10-23 16:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 14:21 [PATCH 00/10] arm64 EFI patches for 3.19 Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 01/10] arm64/efi: efistub: jump to 'stext' directly, not through the header Ard Biesheuvel
2014-10-22 14:47   ` Mark Rutland
2014-10-22 14:21 ` [PATCH 02/10] arm64/efi: set PE/COFF section alignment to 4 KB Ard Biesheuvel
2014-10-22 14:49   ` Mark Rutland
2014-10-22 14:21 ` [PATCH 03/10] arm64/efi: set PE/COFF file alignment to 512 bytes Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 04/10] arm64/efi: reserve regions of type ACPI_MEMORY_NVS Ard Biesheuvel
2014-10-22 16:15   ` Mark Rutland
2014-10-22 16:33     ` Ard Biesheuvel
2014-10-28 10:17       ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 05/10] arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES) Ard Biesheuvel
2014-10-27 12:22   ` Will Deacon
2014-10-22 14:21 ` [PATCH 06/10] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel
2014-10-22 17:06   ` Mark Salter
2014-10-22 17:20     ` Ard Biesheuvel
2014-10-22 17:29       ` Mark Salter
2014-10-23 15:54     ` Mark Rutland
2014-10-23 16:19       ` Mark Salter [this message]
2014-10-23 18:41         ` Ard Biesheuvel
2014-10-23 19:14         ` Mark Rutland
2014-10-23 19:23           ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 07/10] efi: dmi: add support for SMBIOS 3.0 UEFI configuration table Ard Biesheuvel
2014-10-27 15:26   ` Matt Fleming
2014-10-27 15:33     ` Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 08/10] dmi: add support for SMBIOS 3.0 64-bit entry point Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 09/10] arm64: dmi: Add SMBIOS/DMI support Ard Biesheuvel
2014-10-22 14:21 ` [PATCH 10/10] arm64: dmi: set DMI string as dump stack arch description Ard Biesheuvel
2014-10-27 12:24   ` Will Deacon
2014-10-27 12:57     ` Ard Biesheuvel
2014-10-27 11:50 ` [PATCH 00/10] arm64 EFI patches for 3.19 Will Deacon
2014-10-27 12:03   ` Ard Biesheuvel
2014-10-27 17:45     ` Matt Fleming
2014-10-28 12:38       ` Will Deacon

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=1414081198.6829.12.camel@deneb.redhat.com \
    --to=msalter@redhat.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).