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? 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 allocator? Thanks, Pingfan > >> I guess you have a design for future. If not true, then it is better to >> fold the condition "if (kbuf->image->type != KEXEC_TYPE_CRASH)" into the >> caller and rename this function to better distinguish use cases between >> kexec and kdump > > Yeah, this condition will be folded. I have a follow-up patch for that explaining > why kexec case should also be folded. Will try to add that to this series for v2. > > Thanks > Hari > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
