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

Eric W. Biederman
2013-02-08T20:25:33Z

Thomas Renninger <trenn@suse.de> writes:

> On Wednesday, February 06, 2013 03:39:50 PM Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa@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