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.
