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/* and pass it via bootloader structures. 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? Can kexec simply pass the memory to use via memmap=X at Y Then take the original e820 table, but not the usable entries (those are coming from above memmap=X at Y). That would mean that the kexec kernel takes all the original ACPI, ACPI NVS, reserved, unusable (everthing but usable) entries from the original e820 table and identifies the usable memory from memmap boot param? This would be much smarter than trying to pass the mmconf reserved area and I could imagine other issues will show up if the reserved areas do not match the original ones in the kexec kernel. If this really can be done and memmap=exactmap was only used by kexec, it's logic could be redefined from "drop all e820 entries" to "drop all usable e820 entries" and no further adjustings in kexec/kernel are needed to get mmconf working (and other issues may be avoided before they happen). Beside that ACPI reserved aread is not needed anymore to get passed via memmap=X#Y by kexec. Thomas
