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

[H. Peter Anvin]

I would like to see if there is any actual use for it before doing anything else.  The Calgary code may just be off.

On February 24, 2014 7:22:05 AM PST, Vivek Goyal <vgoyal at redhat.com> 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 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

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.