public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Joseph Thelen <jthelen@sgi.com>
Cc: linux-kernel@vger.kernel.org, Alex Thorlton <athorlton@sgi.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-efi@vger.kernel.org,
	Linn Crosetto <linn@hpe.com>, Peter Jones <pjones@redhat.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems
Date: Wed, 8 Jun 2016 13:36:23 +0100	[thread overview]
Message-ID: <20160608123623.GW2658@codeblueprint.co.uk> (raw)
In-Reply-To: <1464900635-11957-2-git-send-email-jthelen@sgi.com>

(Cc'ing people familiar with e820 map woes)

On Thu, 02 Jun, at 03:50:35PM, Joseph Thelen wrote:
> Currently, the EFI memory map entries are disabled by default and must
> be enabled by passing the kernel boot option:
> 
> add_efi_memmap
> 
> The EFI memory map entries should be enabled on systems with more
> than 128 E820 entries, which includes many UV systems. Check if
> we're on a UV system by chekcing the uv system table.
> Enable the EFI memory map entries if we're on a UV system.
> 
> This change is backward compatible because the EFI memory map entries are
> still disabled by default on non-UV systems, and it maintains the previous
> behavior of the kernel boot option. In addition, it allows the EFI memory
> map entries to be explicitly disabled (will not be automatically enabled)
> by setting the add_efi_memmap boot option to anything that kstringtobool
> will determine to be false.
> 
> Signed-off-by: Joseph Thelen <jthelen@sgi.com>
> Cc: Alex Thorlton <athorlton@sgi.com>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: linux-efi@vger.kernel.org
> ---
>  arch/x86/platform/efi/efi.c | 43 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 39 insertions(+), 4 deletions(-)
 
What's the ultimate goal here? To not require that users specify the
add_efi_memmap kernel parameter in the future? Presumably they do
today?

FYI, a lot of non-UV systems have more than 128 entries and the way we
handle it is by using the SETUP_E820_EXT setup_data entry in
boot_params in the EFI boot stub (I don't think boot loaders use it
because they largely go via the stub anyhow).

So if you've got control over your boot loader, and assuming SGI UV
systems don't boot using the EFI boot stub, you could look at adding
boot loader support for SETUP_E820_EXT to force enable > 128 entries
automatically without any new kernel code.

  parent reply	other threads:[~2016-06-08 12:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02 20:50 [RFC PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems Joseph Thelen
2016-06-02 20:50 ` [PATCH] " Joseph Thelen
2016-06-08 11:12   ` Ingo Molnar
2016-06-14 22:19     ` Joseph Thelen
2016-06-08 12:36   ` Matt Fleming [this message]
2016-06-14 22:34     ` Joseph Thelen
2016-06-17 20:57       ` Joseph Thelen

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=20160608123623.GW2658@codeblueprint.co.uk \
    --to=matt@codeblueprint.co.uk \
    --cc=athorlton@sgi.com \
    --cc=hpa@zytor.com \
    --cc=jthelen@sgi.com \
    --cc=linn@hpe.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=pjones@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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