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

Eric W. Biederman ebiederm at xmission.com
Wed Jan 30 16:57:44 EST 2013


"H. Peter Anvin" <hpa at zytor.com> writes:

> On 01/30/2013 10:52 AM, Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa at zytor.com> writes:
>> 
>>> I have to admit to being rather confused as to the separation of various bits of
>>> kdump between the host kernel and various user-space components, but the whole
>>> use of the command line to pass the memory map seems just broken in light of
>>> everything that can go wrong.
>> 
>> It certainly seems time to look at this design decision and see if it
>> still makes sense.
>> 
>> The original idea was to pass the e820 map in the e820 variables, and to
>> slightly override that map to report which memory it was safe for the
>> kdump kernel to run in.  Leaving the kernel with the knowledge that
>> of where everything actually is, and that we just don't happen to be
>> using all of the memory.
>> 
>> Now something seems to have gone wrong with that strategy as we wound
>> up needing to play games with acpi and gart addresses.
>> 
>> I see one of two very basic options going forward.
>> - Pass a kernel command line option that just changes the kernels idea
>>   of which memory it can touch (and we can remove all of the other options).
>> - Modify the e820 map we pass to the kdump kernel and don't bother to
>>   pass anything on the command line.
>> 
>
> Yes, those seem to be the options, and we're currently discussing which one.
>
> The second seems to make more sense to me.  The kexec tools build the
> memory map anyway, and it makes sense to me at least to just build a
> memory map with the appropriate regions marked as a dumpable type.

This dumpable type doesn't make sense to me.  Are you suggesting making
regions that are memory but that we should not use a special memory
type?

I think I would prefer that to call that new type RESERVED_MEM or
RESERVED_CACHABLE.  Being more specific is fine but dumpable certainly
doesn't bring to mind what we are saying.  Especially since we already
communicate which areas were memory to the last kernel in an
architecture generic format.

Eric



More information about the kexec mailing list