On Thu, Jan 10, 2013 at 04:21:49AM +0100, Thomas Renninger wrote: > On Tuesday, January 08, 2013 09:19:18 AM Yinghai Lu wrote: > ... > > > > that exactmap logic still have problem: > > We need to check exactmap at first, aka need to scan the whole comand line > > to see if exactmap is there at first and reset e820 tables then handle > > other memmap opt. > > > > Also please update your patch after > > > > tip/x86/mm2 > > > > I have one patch that process memmap= with "," there. > > > > http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=9710f58 > > 1bb4c35589ac046b0cfc0deb7f369fc85 > > > > We could put exactmap scanning in new parse_memmap_opt. > > I still do not understand why: > > Kexec (kexec/firmware_memmap.c) is setting up the e820 map from: > /sys/firmware/memmap/* Kexe reads it from /sys/firmware/memmap/* because that's supposed to be e820 map as passed by BIOS. And if user has specified some command line options like mem=X, /sys/firmware/memmap/* is not truncated but one exported using /proc/iomem is truncated accordingly. So if we pass mem=1G in first kernel but not in second kernel, we want second kernel to see whole of the system memory and not just 1G. > and pass it via bootloader structures. That's how bootloader is supposed to pass e820 memory map to kernel and kexec is a bootloader. > And this e820 table gets immediately voided by memmap=exactmap > and a new one passed via boot parameters is set up. > If I read this correctly, this is what happens? This happens only in case of kdump and not kexec. In case of kdump we want second kernel to use only selected memory areas. In fact this is one improvement area. Instead of using memmap= entries in kdump case, we should probably modify the e820 map passed in zero page and get rid of memmap= entries. Thanks Vivek
