Re: [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump

From: Thomas Renninger <trenn@suse.de>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: jdmason@kudzu.us, kexec@lists.infradead.org, horms@verge.net.au,
	ebiederm@xmission.com, hpa@zytor.com, dyoung@redhat.com,
	WANG Chao <chaowang@redhat.com>
Subject: Re: [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump
Date: Mon, 24 Feb 2014 16:34:26 +0100	[thread overview]
Message-ID: <1972414.2B2S29ZK0k@skinner> (raw)
In-Reply-To: <20140224152205.GC4631@redhat.com>

On Monday, February 24, 2014 10:22:05 AM Vivek Goyal wrote:
> 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 expected you pass RAM that must not be used as RESERVED. Then, still 
depending on which mem type is the last one, it might have worked.

> 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.

It should be done like that:

The specified_table_size variable must be exported via sysfs.
If kexec-tools finds it existing it can pass in the table size via
boot param:
calgary=
(compare with calgary_parse_options() in arch/x86/kernel/pci-calgary_64.c).

Then the table size detection (for which saved_max_pfn is needed) would
fall off in kdump case.

If this really is supported/relevant, I can send something, but it
would need kexec-tools code as well.

          Thomas

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