[PATCH v2 1/2] fadump: reduce memory consumption for capture kernel

[Hari Bathini]

On Monday 24 April 2017 07:30 PM, Michal Suchánek wrote:
> On Mon, 24 Apr 2017 18:26:37 +0530
> Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
>
>> Hi Michal.
>>
>> On Monday 24 April 2017 03:54 PM, Michal Suchánek wrote:
>>> On Fri, 21 Apr 2017 00:19:55 +0530
>>> Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
>>>   
>>>> On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:
>>>>> On Wed, 19 Apr 2017 14:19:47 +1000
>>>>> Michael Ellerman <mpe at ellerman.id.au> wrote:
>>>>>      
>>>> With the fadump_append= approach I posted in this response thread,
>>>> additional parameters are enforced when fadump is active. If f/w
>>>> supports appending additional parameters, it has to update
>>>> chosen/bootargs whenever fadump is active. Almost the same thing
>>>> except the dirty job is now done by f/w? Hence I thought
>>>> fadump_append= kernel parameter approach is simple and lesser of
>>>> the two evils? Am i missing something here..
>>>>   
>>> The firmware already has to set the parameter by which the kernel
>>> can tell it is a fadump kernel. Hence it already modifies the
>>> devicetree for fadump and you have to rely on it to do so.
>> Right, devicetree is modified to include new 'ibm,kernel-dump' rtas
>> node informing that fadump is active.
>>
>>> The handover area which stores the additional parameters is
>>> reserved by the running kernel so now you also have to rely on the
>>> running kernel, the running kernel and fadum kernel having the same
>>> idea about the location of handover area, the crashing kernel not
>>> randomly overwriting the handover area, etc.
>>>
>>> In short it is additional potential for trouble which can be
>>> avoided.
>>>
>>> I don't know if the firmware does protect the fadump reserved area
>>> and devicetree from being randomly overwritten by the crashing
>>> kernel but it is in the position to do so if desired. The handover
>>> area is controlled by the crashing kernel and cannot have this
>>> guarantee.
>>>
>>>   
>> I thinks there is a mixup here..
>> I am no longer batting for handover area approach but
>> "fadump_append=" approach (suggested by Michael Ellerman in this
>> thread) where there is no need for a handover area but an additional
>> kernel parameter fadump_append=numa=off,nr_cpus=1.. which is a comma
>> separated list of parameters the user wants to enforce when fadump is
>> active.
>>
>> I was trying to say that passing additional parameters with
>> 'fadump_append=' kernel parameter is better over f/w changing the
>> chosen/bootargs node.
>
> Ok, so a fadump specific parameter was just removed in
> 25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one back.

I think you mean commit c2afb7ce9d088696427018ba2135b898058507b8
from linux-next. If so, yes.

> If this is going to be added as an extra kernel parameter can't this be
> passed to kdump kernel as well? Does kdump not have the same
> restrictions?
>

kdump kernel is loaded with kexec and additional parameters can be 
passed to it at the
time of loading. But fadump kernel boots like a regular kernel (through 
f/w & bootloader,
resetting all the h/w) except that f/w guarantees to keep the memory 
intact. So, there is
a need for a different approach to pass additional parameters in case of 
fadump..

Thanks
Hari