mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: jerry.hoemann@hp.com
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: rob@landley.net, tglx@linutronix.de, mingo@redhat.com,
	x86@kernel.org, matt.fleming@intel.com, yinghai@kernel.org,
	penberg@kernel.org, akpm@linux-foundation.org,
	linux-doc@vger.kernel.org, linux-efi@vger.kernel.org,
	vgoyal@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Early use of boot service memory
Date: Wed, 13 Nov 2013 16:57:08 -0700	[thread overview]
Message-ID: <20131113235708.GC25344@anatevka.fc.hp.com> (raw)
In-Reply-To: <52840206.5020006@zytor.com>

On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 02:45 PM, jerry.hoemann@hp.com wrote:
> > 
> > The changes in 3.9 to allow crash kernel to be allocated high helps. 
> > But as you say, the default is still to allocate crash kernel low and
> > still susceptible to this problem.  So, a kdump expert can work around it.
> > But, not everyone is a kdump expert.
> > 
> > So, we can work to change the default, or encourage the distros
> > to always allocate high.  Or, we change the call to efi_reserve_boot_services
> > not apply to all platforms.
> > 
> > The problems for pre 3.9 based distros is worse as they don't have
> > ability to allocate crash kernel high.
> > 
> 
> But they won't have your new option, either,


I am working with distro partners on this issue.
I hope we can find a solution that all can live with.


> 				and that is still horribly
> manual and system-dependent.


I think i can go to a date based black list, that removes the manual
step.  System running firmware before certain date assumes we need
to do the work around.  If firmware is newer than that date, we don't
use the workaround.  Blacklist overrides and allows current behavior
for new firmware that is subsequently found to be broken and for
which we can't convenience the manufacturer to fix.


> 
> In other words, allocating the crashkernel high has ALL the advantages,
> plus a few more, and NONE of the disadvantages.
> 
> 	-hpa

Not exactly.

Firmware shouldn't be accessing these regions after exit boot services.
i like to find/fix firmware bugs.  efi_reserve_boot_services hides this
particular type of error.  Good or bad,  much of platform/firmware
validation is based upon booting/running OSes.

Also, there are kernel/tools rev locks in allocating crash kernel high.
Bigger, more coordination, etc...,


Don't get me wrong.  I think not restricting crash kernel allocation
to low memory is big improvement.  

I will still point out that as currently used, efi_reserve_boot_services
is wrong.  A work around for firmware bugs on one platform shouldn't be
breaking platforms that don't have that bug.  Its just much less likely
to cause problems with higher crash kernel allocation.




-- 

----------------------------------------------------------------------------
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-13 23:57 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
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 [this message]
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=20131113235708.GC25344@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

Powered by JetHome