On Wed, Jan 9, 2013 at 7:21 PM, Thomas Renninger <trenn@xxxxxxx> wrote: > 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? yes, kdump scripts append those memmap. > > Can kexec simply pass the memory to use via memmap=X@Y > Then take the original e820 table, but not the usable entries (those > are coming from above memmap=X@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? kdump scripts already do that for acpi regions, need to update it to append that for mmconf. > > 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. yes, we have other user for debug like simulating user memmap for some bugs. current problem for exactmap is that we don't scan that at first. attached patch could help that. Thanks Yinghai
Attachment:
parse_exactmap_one_time.patch
Description: Binary data
