Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1422415 > unrolled thread

Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems Joseph Thelen <jthelen@sgi.com> - 2016-06-15 00:40 +0200
    Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems Joseph Thelen <jthelen@sgi.com> - 2016-06-17 23:00 +0200

#1422415 — Re: [PATCH] x86/efi: Auto enable EFI memmap on SGI UV systems

On Wed, Jun 08, 2016 at 01:36:23PM +0100, Matt Fleming wrote:
> (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.

We're still reasonably confident we'll need something like this. Although,
after looking into the stuff you mention, it seems that it should perhaps
be a bit more sophisticated than just checking if we're on a UV system.

We'll get back to you after digging into this a bit more and coming
up with some more specific reasons for the change.

Thanks,

Joseph Thelen

[toc] | [next] | [standalone]

#1425473

On Tue, Jun 14, 2016 at 05:34:49PM -0500, Joseph Thelen wrote:
> We're still reasonably confident we'll need something like this. Although,
> after looking into the stuff you mention, it seems that it should perhaps
> be a bit more sophisticated than just checking if we're on a UV system.
> 
> We'll get back to you after digging into this a bit more and coming
> up with some more specific reasons for the change.
> 
> Thanks,
> 
> Joseph Thelen
>

After investigating a bit more, it seems that this is really only
an issue where people are using older bootloaders/managers and kernels, some
of which are still supported / used by big distros like redhat.

Given that this is, as you've pointed out, either a non-issue or easily
remedied without kernel changes now and in the future, we'll try
talking about it directly with any distro where it's still an issue.

Thanks,

Joseph Thelen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web