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
