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

[H. Peter Anvin]

On 02/06/2013 03:04 PM, Eric W. Biederman wrote:
>>
>> There is another important point, why the command line approach
>> should be preferred:
>> Backward compatibility and the ability to backport the whole stuff to
>> fix mmconf in kdump which would be nice for example for SLES11.
> 
> Backward compatibility argues for editing the e820 map because we can do
> that at any time, with no dependencies on any kernel changes.  Only
> the E820_RAM type will be treated as ram.  Any unregcognized e820 type
> will be treated as reserved.  The code has always been like that.
> 
> A new reserved value would be nice to communicate to the kernel areas
> that are really ram but it isn't allowed to touch but is unnecessary at
> this point.  Even with just marking memory regions we don't use as
> E820_RESERVED we match what is currently being done.
> 
> Since a new reserved value has not been selected let me suggest.
> 0x6b646d70 aka kdmp in asii.
> 

I (somewhat) would like to keep the reserved numbers in a small(ish)
range which argue against that specific constant.  I kind of like
0x6bxxxxxx ("k") though, it has some flair to it.

> For backwards compatibility I prefer editing the e820 map in
> /sbin/kexec.
> 
> 
> My real preference would be to define a command line option that will
> work on all architectures that implement kdump, as the craskernel option
> does.  Unfortunately it looks like that ship has sailed, and there isn't
> enough desire to fix this to come up with a generic option that will
> work on more than just x86.  But if we could get past the kernel
> versioning and figure out a arch-generic solution it might be worth it.
> 

What would that option look like?

>> kexec-tools can detect the kernel version of the kernel which is loaded
>> as kdump/crash kernel. If its version is:
>> "$MAINLINE_VERSION_THE_CHANGE_GETS_INTRODUCED"
>> or newer, things are fine.
>> But if the kernel version is older, there is no way for kexec-tools to
>> find out whether the older kernel may have the feature included.
>> That's bad!
> 
> That is totally unnecessary for the e820 map because anything
> unrecognized is treated as reserved, and for the sufficiently paranoid
> we don't need to use a new memory type.

The only issue is if kdump needs the memory it is going to dump to be
mapped; we don't map reserved memory anymore unless explicitly requested
via ioremap().  Does it?

> The existing e820 handling for unknown type is much much better.  It
> just treats them as reserved and goes about it's merry way.

It sounds like this is the way to go.

	-hpa