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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux