[PATCH 0/3] Cleanup kdump memmap= passing and e820 usage

[Eric W. Biederman]

Thomas Renninger <trenn at suse.de> writes:

> On Wednesday, February 06, 2013 03:39:50 PM Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa at zytor.com> writes:

>> >> The existing e820 handling for unknown type is much much better.  It
>> >> just treats them as reserved and goes about it's merry way.
> If the new kdump type is treated as reserved and things work out,
> I agree that this would be the most elegant approach, especially also
> for backporting etc.

Only kexec-tools needs the functionality so no kernel level backporting
is necessary.

> In a kernel which has the patch/functionality backported I would do
> it like this then:
>   - If the special kdump e820 type shows up, all memmap options from
>     memmap=exactmap on are ignored and the kexec-tools passed
>     e820 table is used just as it is.
>     -> This would still allow e820 modifcations through memmap=
>     if passed manually for debugging, they just have to show up before
>     the kexec-tools generated ones. Anyway, I will also send a patch
>     how I think this can be backported and still work with old and new
>     kexec-tools versions.

Way over complicated.  kexec-tools can just stop passing the memmap=
options entirely for every kernel.

We have not actually identified a use that the kernel would make of the
reserved areas.  Comming up with a new mapping type is just hedging our
bets in case there is a reason we want to know what is actually RAM at
some point in the future.

>> > It sounds like this is the way to go.
>> 
>> It certainly looks good.  We still need someone with the time to write
>> the patch and test it.
>
> I try to find time for this early next week to code something together and
> already give it some testing, but I cannot promise anything.
>
> Thanks everybody for the help to find the best solution,

Eric