On 30/06/20 9:00 am, piliu wrote:
> On 06/29/2020 01:55 PM, Hari Bathini wrote:
>> On 28/06/20 7:44 am, piliu wrote:
>>> Hi Hari,
>> Hi Pingfan,
>>> After a quick through for this series, I have a few question/comment on
>>> this patch for the time being. Pls see comment inline.
>>> On 06/27/2020 03:05 AM, Hari Bathini wrote:
>>>> crashkernel region could have an overlap with special memory regions
>>>> like opal, rtas, tce-table & such. These regions are referred to as
>>>> exclude memory ranges. Setup this ranges during image probe in order
>>>> to avoid them while finding the buffer for different kdump segments.
>>>> + /*
>>>> + * Use the locate_mem_hole logic in kexec_add_buffer() for regular
>>>> + * kexec_file_load syscall
>>>> + */
>>>> + if (kbuf->image->type != KEXEC_TYPE_CRASH)
>>>> + return 0;
>>> Can the ranges overlap [crashk_res.start, crashk_res.end]? Otherwise
>>> there is no requirement for @exclude_ranges.
>> The ranges like rtas, opal are loaded by f/w. They almost always overlap with
>> crashkernel region. So, @exclude_ranges is required to support kdump.
> f/w passes rtas/opal as service, then must f/w mark these ranges as
> fdt_reserved_mem in order to make kernel aware not to use these ranges?
It does. Actually, reserve_map + reserved-ranges are reserved as soon as
memblock allocator is ready but not before crashkernel reservation.
Check early_reserve_mem() call in kernel/prom.c
> Otherwise kernel memory allocation besides kdump can also overwrite
> these ranges.>
> Hmm, revisiting reserve_crashkernel(). It seems not to take any reserved
> memory into consider except kernel text. Could it work based on memblock
So, kdump could possibly overwrite these regions which is why an exclude
range list is needed. Same thing was done in kexec-tools as well.