[PATCH] Reserve memory for kdump kernel within RMO region

[M. Mohan Kumar]

On 11/26/2009 12:22 AM, Bernhard Walle wrote:
> M. Mohan Kumar schrieb:
>> Reserve memory for kdump kernel within RMO region
>>
>> When the kernel size exceeds 32MB(observed with some distros), memory
>> for kdump kernel can not be reserved as kdump kernel base is assumed to
>> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
>> provide the feature to reserve the memory for kdump kernel anywhere in
>> the RMO region.
>

Hi Bernhard,

> Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
> gets loaded as crashkernel, not for the kernel that loads the
> crashkernel. So it would be perfectly fine that a kernel that has not
> CONFIG_RELOCATABLE set would load another kernel that has
> CONFIG_RELOCATABLE set on an address != 32 M.

No, with relocatable option, the same kernel is used as both production 
and kdump kernel. If the kernel is not relocatable, kdump kernel can be 
loaded *only at* 32MB. So if a kernel has RELOCATABLE option enabled and 
by chance if the production kernel size is beyond 32MB, current code 
will not load the kdump kernel at 32MB as current kernel overlaps with 
kdump kernel region. So if the kernel has RELOCATABLE option, we could 
reserve memory for kdump kernel within RMO region.

>
> So it would be part of the command line to determine whether a fixed or
> a variable address is used. The system configuration (or the admin)
> knows both: if the kernel that should be loaded is relocatable (can be
> detected with the x86 bzImage header or with the ELF type for vmlinux)
> and it can also influence the boot command line.
>
> To sum it up: I'm not against reserving it anywhere, I'm only against
> making it dependent on CONFIG_RELOCATABLE which has another function.
>
>
>
> Regards,
> Bernhard
>
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec