public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@elte.hu>,
	kexec <kexec@lists.infradead.org>,
	caiqian@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_"
Date: Tue, 28 Sep 2010 09:54:49 -0400	[thread overview]
Message-ID: <20100928135449.GA8950@redhat.com> (raw)
In-Reply-To: <4CA16522.8060107@zytor.com>

On Mon, Sep 27, 2010 at 08:46:42PM -0700, H. Peter Anvin wrote:
> On 09/27/2010 05:53 PM, Vivek Goyal wrote:
> > 
> > Actually, hardcoding the upper limit to 4G is probably not the best idea.
> > Kexec loads the the relocatable binary (purgatory) and I remember that
> > one of the generated relocation type was signed 32 bit and allowed max value
> > to be 2G only. So IIRC, purgatory code always needed to be loaded below 2G.
> > 
> > I liked HPA's other idea better of introducing memblock_find_in_range_lowest() 
> > so that we search bottom up and not rely on a specific upper limit.
> > 
> 
> No, it's just another crappy hack which is broken in the same way.  It's
> better than open-coding, but it's still a hack.
> 
> The Right Thing[TM] to do is for kexec to communicate the topmost
> address it wants to this code, so it has both the upper and the lower
> boundaries available to it instead of just one.
> 

Being able to specify the upper limit would be the best thing so that
kernel does not have to make any assumptions or hardcode anything.

Question is how to determine the upper limit.

- The upper limit will depend on what is being loaded in reserved region.
  Reserving memory using crashkernel= is a boot time optin and that point
  of time kexec has not even run. So we don't know what is the upper
  limit.

  Now we can do extra reboot to make it happen. Boot first kernel without
  reserving any memory. Introduce an option in kexec which tells user what
  are the segments kexec would like to load (for a given binary) and what
  are there upper memory limits and then user goes ahead modifies the
  command line and reboots the kernel back.

  This all sounds not so clean. Especially upper limit might change based
  on binary being loaded and a user might have to perform a reboot again.

So to me trying to get lowest memory available possible for crashkernel
reservations is not that a bad idea. It is certainly better than making
hardcoded assumptions about the upper limit.

Thanks
Vivek

  parent reply	other threads:[~2010-09-28 13:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1909915255.2046011285586388234.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-09-27 11:21 ` kexec load failure introduced by "x86, memblock: Replace e820_/_early string with memblock_" caiqian
2010-09-27 22:22   ` Yinghai Lu
2010-09-27 22:50     ` H. Peter Anvin
2010-09-27 23:20       ` Yinghai Lu
2010-09-27 23:26         ` H. Peter Anvin
2010-09-27 23:32           ` Yinghai Lu
2010-09-27 23:34             ` H. Peter Anvin
2010-09-27 23:41               ` Yinghai Lu
2010-09-28  0:53                 ` Vivek Goyal
2010-09-28  2:41                   ` Yinghai Lu
2010-09-28  3:46                   ` H. Peter Anvin
2010-09-28  7:14                     ` Yinghai Lu
2010-09-28 14:01                       ` Vivek Goyal
2010-09-28 13:54                     ` Vivek Goyal [this message]
     [not found] <870873343.2003871285555329846.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-09-27  6:31 ` Yinghai Lu
2010-09-27  9:16   ` CAI Qian

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=20100928135449.GA8950@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=caiqian@redhat.com \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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