All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: WANG Chao <chaowang@redhat.com>
Cc: jdmason@kudzu.us, kexec@lists.infradead.org, horms@verge.net.au,
	ebiederm@xmission.com, hpa@zytor.com, dyoung@redhat.com,
	Thomas Renninger <trenn@suse.de>
Subject: Re: [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump
Date: Mon, 24 Feb 2014 10:22:05 -0500	[thread overview]
Message-ID: <20140224152205.GC4631@redhat.com> (raw)
In-Reply-To: <20140224145841.GE1262@dhcp-17-89.nay.redhat.com>

On Mon, Feb 24, 2014 at 10:58:41PM +0800, WANG Chao wrote:
[..]
> > Approaches to avoid saved_max_pfn in calgary case:
> >   1) If done correctly from the beginning, the TCE table size would have
> >      been exposed via /sys and kexec-tools could simply add:
> >      calgary="128k|512K...|8M" which is already caught by pci-calgary and
> >      saved_max_pfn is not needed/touched anymore.
> >      -> Disadvantage: needs a new sysfs entry
> >   2) When finding max_pfn for calgary table size usage, we could try in 
> >      kdump case to use the highest memory (RAM or RESERVED) showing up
> >      in e820 map.
> 
> How could this replace saved_max_pfn? The highest memory in kdump can't
> necessarily be the real ram size. In kdump, RAM range is just part of the real
> ram, not mentioning we don't pass RESERVED range to kdump E820.

I vaguely remember there was some discussion about passing first kerne's
RAM as special reserved ranges. Say E820_RESERVED_KDUMP. And use that
to figure out saved_max_pfn.

I personally feel that just create a new command line parameter
"saved_max_pfn" and pass it to second kernel and be done with it. Modify
calgary code to first look for saved_max_pfn and if not present, calculate
saved_max_pfn from e820.

saved_max_pfn command line option is pretty ugly, not sure what are the
better options here.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2014-02-24 15:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20  9:28 [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump WANG Chao
2014-02-20  9:28 ` [PATCH v2 1/4] cleanup: add dbgprint_mem_range function WANG Chao
2014-02-20  9:28 ` [PATCH v2 2/4] x86: Store memory ranges globally used for crash kernel to boot into WANG Chao
2014-02-20  9:28 ` [PATCH v2 3/4] x86: add --pass-memmap-cmdline option WANG Chao
2014-02-20  9:28 ` [PATCH v2 4/4] x86: Pass memory range via E820 for kdump WANG Chao
2014-02-27 20:53   ` Linn Crosetto
2014-02-28  8:32     ` WANG Chao
2014-02-24 10:38 ` [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass " Thomas Renninger
2014-02-24 14:58   ` WANG Chao
2014-02-24 15:03     ` H. Peter Anvin
2014-02-24 15:11       ` Vivek Goyal
2014-02-24 15:24         ` Vivek Goyal
2014-02-24 15:28           ` H. Peter Anvin
2014-02-24 15:22     ` Vivek Goyal [this message]
2014-02-24 15:27       ` H. Peter Anvin
2014-02-24 15:34       ` Thomas Renninger
2014-02-24 15:45         ` Vivek Goyal
2014-02-24 15:50           ` H. Peter Anvin
2014-02-24 15:59             ` 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=20140224152205.GC4631@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=jdmason@kudzu.us \
    --cc=kexec@lists.infradead.org \
    --cc=trenn@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.