mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: jerry.hoemann@hp.com
To: Pekka Enberg <penberg@kernel.org>
Cc: Rob Landley <rob@landley.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86 maintainers <x86@kernel.org>,
	Matt Fleming <matt.fleming@intel.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"list@ebiederm.org:DOCUMENTATION <linux-doc@vger.kernel.org>,
	list@ebiederm.org:MEMORY MANAGEMENT <linux-mm@kvack.org>," 
	<linux-doc@vger.kernel.org>,
	linux-efi@vger.kernel.org, Vivek Goyal <vgoyal@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Early use of boot service memory
Date: Tue, 12 Nov 2013 10:55:01 -0700	[thread overview]
Message-ID: <20131112175500.GA22363@anatevka.fc.hp.com> (raw)
In-Reply-To: <CAOJsxLEoN2uYR9V3bowv2O7F8L5t+kVrdehHW151cEcfgx-oJg@mail.gmail.com>

On Tue, Nov 12, 2013 at 12:37:29PM +0200, Pekka Enberg wrote:
> On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann <jerry.hoemann@hp.com> wrote:
> > Some platform have firmware that violates UEFI spec and access boot service
> > code or data segments after the system has called Exit Boot Services.
> > The call to efi_reserve_boot_services in setup_arch is a work around to
> > avoid using boot service memory until after the kernel has done
> > Set Virtual Map.
> >
> > However, this reservation fragments memory which can cause
> > large allocations early in boot (e.g. crash kernel) to fail.
> 
> What is the exact problem you're trying to solve here?

Pekka,

My primary motivation is fixing an issue that can causes kdump
to be disabled on a system.


Sequence of events:

1. The kernel calls efi_reserve_boot_services during setup_arch.

2. efi_reserve_boot_services reserves memory regions of type
   EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA.

3. setup_arch calls reserve_crashkernel().

4. start_kernel calls efi_free_boot_services which frees up the
   memory reserved by efi_reserve_boot_services().


The problem is that dependent upon the size of the crash kernel reservation,
the layout of the memory, and the location of the Boot Service Code and
Data segments,  reserve_crashkernel could fail where it would have
succeeded if the call to efi_reserve_boot_services hadn't been
made.

When reserve_crashkernel fails, kdump will be disabled.

The problem is made more apparent as large servers need large crash
kernel allocations.

The UEFI spec states that BS Code and Data segments are free
to be reused by an operating system after call to Exit Boot
Services.   Unfortunately,  some platforms apparently violate this 
portion of the spec and will use these segments as part of
the call to Set Virtual Map.  This can cause the system to crash
if Linux changed the content of the memory.

Hence,  the call to efi_reserve_boot_services was added as
a work around to platforms that violated this portion of the
UEFI spec.

Unfortunately,  the work around causes problems as described above.



For more background on efi_reserve_boot_services, please consult the thread:
https://lkml.org/lkml/2013/7/31/553



> How will the 
> problem be fixed for platforms that break the UEFI specification?
> 
>                         Pekka

My change does not address platforms that have misbehaving firmware.
It just allows platforms that don't have this issue to avoid issues
that the call to efi_reserve_boot_services presents.


Jerry


-- 

----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer              Hewlett-Packard/MODL

3404 E Harmony Rd. MS 57                        phone:  (970) 898-1022
Ft. Collins, CO 80528                           FAX:    (970) 898-XXXX
                                                email:  jerry.hoemann@hp.com
----------------------------------------------------------------------------


  reply	other threads:[~2013-11-12 17:55 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  2:15 Jerry Hoemann
2013-11-12  2:15 ` [PATCH 1/3] efi: " Jerry Hoemann
2013-11-12  2:15 ` [PATCH 2/3] x86: avoid efi_reserve_boot_services Jerry Hoemann
2013-11-12  2:15 ` [PATCH 3/3] x86, efi: Early use of boot service memory Jerry Hoemann
2013-11-12 10:37 ` [PATCH 0/3] " Pekka Enberg
2013-11-12 17:55   ` jerry.hoemann [this message]
2013-11-12 18:48     ` Pekka Enberg
2013-11-12 21:52       ` jerry.hoemann
2013-11-12 18:58 ` H. Peter Anvin
2013-11-13 22:45   ` jerry.hoemann
2013-11-13 22:49     ` H. Peter Anvin
2013-11-13 23:57       ` jerry.hoemann
2013-11-14  0:05         ` H. Peter Anvin
2013-11-14  1:40           ` jerry.hoemann
2014-08-01  9:54           ` Yuhong Bao
2013-11-14  8:24         ` Pekka Enberg
2013-11-14 18:04           ` jerry.hoemann
2013-11-14 18:44             ` Pekka Enberg
2013-11-14 18:45               ` H. Peter Anvin
2013-11-15  0:50               ` jerry.hoemann
2013-11-15  6:24                 ` Ingo Molnar
2013-11-15  6:55                   ` Yinghai Lu
2013-11-15  6:59                     ` H. Peter Anvin
2013-11-15 14:07                       ` Vivek Goyal
2013-11-15 17:33                         ` Yinghai Lu
2013-11-15 17:40                           ` H. Peter Anvin
2013-11-15 18:30                             ` Vivek Goyal
2013-11-15 18:46                               ` H. Peter Anvin
2013-11-15 19:16                                 ` H. Peter Anvin
2013-11-18 15:22                                   ` Vivek Goyal
2013-11-18 18:29                                     ` H. Peter Anvin
2013-11-18 18:52                                       ` Vivek Goyal
2013-11-19  1:32                               ` H. Peter Anvin
2013-11-19  3:02                                 ` Yinghai Lu
2013-11-15 18:03                           ` Vivek Goyal
2013-11-15 22:24                             ` Yinghai Lu
2013-11-15 22:55                               ` jerry.hoemann
2013-11-15 23:43                                 ` Yinghai Lu
2013-11-18 15:32                               ` Vivek Goyal
2013-11-18 19:34                                 ` Yinghai Lu
2013-11-18 19:39                                   ` Vivek Goyal
2013-11-15 18:16                       ` jerry.hoemann
2013-11-15 19:13                   ` jerry.hoemann
2013-11-18 15:42                     ` Vivek Goyal
2013-11-15  8:36                 ` Pekka Enberg
2013-11-14 15:26       ` Vivek Goyal

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=20131112175500.GA22363@anatevka.fc.hp.com \
    --to=jerry.hoemann@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=mingo@redhat.com \
    --cc=penberg@kernel.org \
    --cc=rob@landley.net \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=yinghai@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

all inboxes | Powered by JetHome®