Re: [PATCH] Only reset e820 once, even with multiple memmap=exactmap params

[Thomas Renninger]

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@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?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/