Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
> > I'm confused about the "overlap with crashkernel memory", does that mean > > those normal kernel used memory could be put in crashkernel reserved > > memory range? If so why can't just skip those areas while crashkernel > > doing the reservation? > I raised the same question in another mail. As Hari's answer, "kexec -p" > skips these ranges in user space. And the same logic should be done in > "kexec -s -p" See it, thanks! The confusion also applied to the userspace implementation though. Seems they have to be special cases because of the powerpc crashkernel reservation implemtation in kernel limitation Thanks Dave
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
On 07/01/20 at 11:48pm, Hari Bathini wrote:
>
>
> On 01/07/20 1:10 pm, Dave Young wrote:
> > Hi Hari,
> > On 06/27/20 at 12:35am, 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.
> >> Implement kexec_locate_mem_hole_ppc64() that locates a memory hole
> >> accounting for these ranges. Also, override arch_kexec_add_buffer()
> >> to locate a memory hole & later call __kexec_add_buffer() function
> >> with kbuf->mem set to skip the generic locate memory hole lookup.
> >>
> >> Signed-off-by: Hari Bathini
> >> ---
> >> arch/powerpc/include/asm/crashdump-ppc64.h | 10 +
> >> arch/powerpc/include/asm/kexec.h |7 -
> >> arch/powerpc/kexec/elf_64.c|7 +
> >> arch/powerpc/kexec/file_load_64.c | 292
> >>
> >> 4 files changed, 312 insertions(+), 4 deletions(-)
> >> create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h
> >>
> > [snip]
> >> /**
> >> + * get_exclude_memory_ranges - Get exclude memory ranges. This list
> >> includes
> >> + * regions like opal/rtas, tce-table, initrd,
> >> + * kernel, htab which should be avoided while
> >> + * setting up kexec load segments.
> >> + * @mem_ranges:Range list to add the memory ranges to.
> >> + *
> >> + * Returns 0 on success, negative errno on error.
> >> + */
> >> +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges)
> >> +{
> >> + int ret;
> >> +
> >> + ret = add_tce_mem_ranges(mem_ranges);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_initrd_mem_range(mem_ranges);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_htab_mem_range(mem_ranges);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_kernel_mem_range(mem_ranges);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_rtas_mem_range(mem_ranges, false);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_opal_mem_range(mem_ranges, false);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + ret = add_reserved_ranges(mem_ranges);
> >> + if (ret)
> >> + goto out;
> >> +
> >> + /* exclude memory ranges should be sorted for easy lookup */
> >> + sort_memory_ranges(*mem_ranges);
> >> +out:
> >> + if (ret)
> >> + pr_err("Failed to setup exclude memory ranges\n");
> >> + return ret;
> >> +}
> >
> > I'm confused about the "overlap with crashkernel memory", does that mean
> > those normal kernel used memory could be put in crashkernel reserved
>
> There are regions that could overlap with crashkernel region but they are
> not normal kernel used memory though. These are regions that kernel and/or
> f/w chose to place at a particular address for real mode accessibility
> and/or memory layout between kernel & f/w kind of thing.
>
> > memory range? If so why can't just skip those areas while crashkernel
> > doing the reservation?
>
> crashkernel region has a dependency to be in the first memory block for it
> to be accessible in real mode. Accommodating this requirement while addressing
> other requirements would mean something like what we have now. A list of
> possible special memory regions in crashkernel region to take care of.
>
> I have plans to split crashkernel region into low & high to have exclusive
> regions for crashkernel, even if that means to have two of them. But that
> is for another day with its own set of complexities to deal with...
Ok, I was not aware the powerpc crashkernel reservation is not
dynamically reserved. But seems powerpc need those tricks at least for
the time being like you said.
Thanks
Dave
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
On 01/07/20 1:10 pm, Dave Young wrote:
> Hi Hari,
> On 06/27/20 at 12:35am, 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.
>> Implement kexec_locate_mem_hole_ppc64() that locates a memory hole
>> accounting for these ranges. Also, override arch_kexec_add_buffer()
>> to locate a memory hole & later call __kexec_add_buffer() function
>> with kbuf->mem set to skip the generic locate memory hole lookup.
>>
>> Signed-off-by: Hari Bathini
>> ---
>> arch/powerpc/include/asm/crashdump-ppc64.h | 10 +
>> arch/powerpc/include/asm/kexec.h |7 -
>> arch/powerpc/kexec/elf_64.c|7 +
>> arch/powerpc/kexec/file_load_64.c | 292
>>
>> 4 files changed, 312 insertions(+), 4 deletions(-)
>> create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h
>>
> [snip]
>> /**
>> + * get_exclude_memory_ranges - Get exclude memory ranges. This list includes
>> + * regions like opal/rtas, tce-table, initrd,
>> + * kernel, htab which should be avoided while
>> + * setting up kexec load segments.
>> + * @mem_ranges:Range list to add the memory ranges to.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges)
>> +{
>> +int ret;
>> +
>> +ret = add_tce_mem_ranges(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_initrd_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_htab_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_kernel_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_rtas_mem_range(mem_ranges, false);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_opal_mem_range(mem_ranges, false);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_reserved_ranges(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +/* exclude memory ranges should be sorted for easy lookup */
>> +sort_memory_ranges(*mem_ranges);
>> +out:
>> +if (ret)
>> +pr_err("Failed to setup exclude memory ranges\n");
>> +return ret;
>> +}
>
> I'm confused about the "overlap with crashkernel memory", does that mean
> those normal kernel used memory could be put in crashkernel reserved
There are regions that could overlap with crashkernel region but they are
not normal kernel used memory though. These are regions that kernel and/or
f/w chose to place at a particular address for real mode accessibility
and/or memory layout between kernel & f/w kind of thing.
> memory range? If so why can't just skip those areas while crashkernel
> doing the reservation?
crashkernel region has a dependency to be in the first memory block for it
to be accessible in real mode. Accommodating this requirement while addressing
other requirements would mean something like what we have now. A list of
possible special memory regions in crashkernel region to take care of.
I have plans to split crashkernel region into low & high to have exclusive
regions for crashkernel, even if that means to have two of them. But that
is for another day with its own set of complexities to deal with...
Thanks
Hari
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
On 07/01/2020 03:40 PM, Dave Young wrote:
> Hi Hari,
> On 06/27/20 at 12:35am, 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.
>> Implement kexec_locate_mem_hole_ppc64() that locates a memory hole
>> accounting for these ranges. Also, override arch_kexec_add_buffer()
>> to locate a memory hole & later call __kexec_add_buffer() function
>> with kbuf->mem set to skip the generic locate memory hole lookup.
>>
>> Signed-off-by: Hari Bathini
>> ---
>> arch/powerpc/include/asm/crashdump-ppc64.h | 10 +
>> arch/powerpc/include/asm/kexec.h |7 -
>> arch/powerpc/kexec/elf_64.c|7 +
>> arch/powerpc/kexec/file_load_64.c | 292
>>
>> 4 files changed, 312 insertions(+), 4 deletions(-)
>> create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h
>>
> [snip]
>> /**
>> + * get_exclude_memory_ranges - Get exclude memory ranges. This list includes
>> + * regions like opal/rtas, tce-table, initrd,
>> + * kernel, htab which should be avoided while
>> + * setting up kexec load segments.
>> + * @mem_ranges:Range list to add the memory ranges to.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges)
>> +{
>> +int ret;
>> +
>> +ret = add_tce_mem_ranges(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_initrd_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_htab_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_kernel_mem_range(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_rtas_mem_range(mem_ranges, false);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_opal_mem_range(mem_ranges, false);
>> +if (ret)
>> +goto out;
>> +
>> +ret = add_reserved_ranges(mem_ranges);
>> +if (ret)
>> +goto out;
>> +
>> +/* exclude memory ranges should be sorted for easy lookup */
>> +sort_memory_ranges(*mem_ranges);
>> +out:
>> +if (ret)
>> +pr_err("Failed to setup exclude memory ranges\n");
>> +return ret;
>> +}
>
> I'm confused about the "overlap with crashkernel memory", does that mean
> those normal kernel used memory could be put in crashkernel reserved
> memory range? If so why can't just skip those areas while crashkernel
> doing the reservation?
I raised the same question in another mail. As Hari's answer, "kexec -p"
skips these ranges in user space. And the same logic should be done in
"kexec -s -p"
Regards,
Pingfan
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
Hi Hari,
On 06/27/20 at 12:35am, 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.
> Implement kexec_locate_mem_hole_ppc64() that locates a memory hole
> accounting for these ranges. Also, override arch_kexec_add_buffer()
> to locate a memory hole & later call __kexec_add_buffer() function
> with kbuf->mem set to skip the generic locate memory hole lookup.
>
> Signed-off-by: Hari Bathini
> ---
> arch/powerpc/include/asm/crashdump-ppc64.h | 10 +
> arch/powerpc/include/asm/kexec.h |7 -
> arch/powerpc/kexec/elf_64.c|7 +
> arch/powerpc/kexec/file_load_64.c | 292
>
> 4 files changed, 312 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h
>
[snip]
> /**
> + * get_exclude_memory_ranges - Get exclude memory ranges. This list includes
> + * regions like opal/rtas, tce-table, initrd,
> + * kernel, htab which should be avoided while
> + * setting up kexec load segments.
> + * @mem_ranges:Range list to add the memory ranges to.
> + *
> + * Returns 0 on success, negative errno on error.
> + */
> +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges)
> +{
> + int ret;
> +
> + ret = add_tce_mem_ranges(mem_ranges);
> + if (ret)
> + goto out;
> +
> + ret = add_initrd_mem_range(mem_ranges);
> + if (ret)
> + goto out;
> +
> + ret = add_htab_mem_range(mem_ranges);
> + if (ret)
> + goto out;
> +
> + ret = add_kernel_mem_range(mem_ranges);
> + if (ret)
> + goto out;
> +
> + ret = add_rtas_mem_range(mem_ranges, false);
> + if (ret)
> + goto out;
> +
> + ret = add_opal_mem_range(mem_ranges, false);
> + if (ret)
> + goto out;
> +
> + ret = add_reserved_ranges(mem_ranges);
> + if (ret)
> + goto out;
> +
> + /* exclude memory ranges should be sorted for easy lookup */
> + sort_memory_ranges(*mem_ranges);
> +out:
> + if (ret)
> + pr_err("Failed to setup exclude memory ranges\n");
> + return ret;
> +}
I'm confused about the "overlap with crashkernel memory", does that mean
those normal kernel used memory could be put in crashkernel reserved
memory range? If so why can't just skip those areas while crashkernel
doing the reservation?
Thanks
Dave
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
On 06/30/2020 02:10 PM, Hari Bathini wrote: > > > 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 >> allocator? > > 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. OK, got it. Thanks, Pingfan > > Thanks > Hari > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
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 > allocator? 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. Thanks Hari
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
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 >
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
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. > 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
Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions
Hi Hari,
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.
> Implement kexec_locate_mem_hole_ppc64() that locates a memory hole
> accounting for these ranges. Also, override arch_kexec_add_buffer()
> to locate a memory hole & later call __kexec_add_buffer() function
> with kbuf->mem set to skip the generic locate memory hole lookup.
>
> Signed-off-by: Hari Bathini
> ---
> arch/powerpc/include/asm/crashdump-ppc64.h | 10 +
> arch/powerpc/include/asm/kexec.h |7 -
> arch/powerpc/kexec/elf_64.c|7 +
> arch/powerpc/kexec/file_load_64.c | 292
>
> 4 files changed, 312 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h
>
> diff --git a/arch/powerpc/include/asm/crashdump-ppc64.h
> b/arch/powerpc/include/asm/crashdump-ppc64.h
> new file mode 100644
> index 000..3596c25
> --- /dev/null
> +++ b/arch/powerpc/include/asm/crashdump-ppc64.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#ifndef _ARCH_POWERPC_KEXEC_CRASHDUMP_PPC64_H
> +#define _ARCH_POWERPC_KEXEC_CRASHDUMP_PPC64_H
> +
> +/* min & max addresses for kdump load segments */
> +#define KDUMP_BUF_MIN(crashk_res.start)
> +#define KDUMP_BUF_MAX((crashk_res.end < ppc64_rma_size) ? \
> + crashk_res.end : (ppc64_rma_size - 1))
> +
> +#endif /* __ARCH_POWERPC_KEXEC_CRASHDUMP_PPC64_H */
> diff --git a/arch/powerpc/include/asm/kexec.h
> b/arch/powerpc/include/asm/kexec.h
> index 7008ea1..bf47a01 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -100,14 +100,16 @@ void relocate_new_kernel(unsigned long
> indirection_page, unsigned long reboot_co
> #ifdef CONFIG_KEXEC_FILE
> extern const struct kexec_file_ops kexec_elf64_ops;
>
> -#ifdef CONFIG_IMA_KEXEC
> #define ARCH_HAS_KIMAGE_ARCH
>
> struct kimage_arch {
> + struct crash_mem *exclude_ranges;
> +
> +#ifdef CONFIG_IMA_KEXEC
> phys_addr_t ima_buffer_addr;
> size_t ima_buffer_size;
> -};
> #endif
> +};
>
> int setup_purgatory(struct kimage *image, const void *slave_code,
> const void *fdt, unsigned long kernel_load_addr,
> @@ -125,6 +127,7 @@ int setup_new_fdt_ppc64(const struct kimage *image, void
> *fdt,
> unsigned long initrd_load_addr,
> unsigned long initrd_len, const char *cmdline);
> #endif /* CONFIG_PPC64 */
> +
> #endif /* CONFIG_KEXEC_FILE */
>
> #else /* !CONFIG_KEXEC_CORE */
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index 23ad04c..c695f94 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> static void *elf64_load(struct kimage *image, char *kernel_buf,
> unsigned long kernel_len, char *initrd,
> @@ -46,6 +47,12 @@ static void *elf64_load(struct kimage *image, char
> *kernel_buf,
> if (ret)
> goto out;
>
> + if (image->type == KEXEC_TYPE_CRASH) {
> + /* min & max buffer values for kdump case */
> + kbuf.buf_min = pbuf.buf_min = KDUMP_BUF_MIN;
> + kbuf.buf_max = pbuf.buf_max = KDUMP_BUF_MAX;
> + }
> +
> ret = kexec_elf_load(image, , _info, , _load_addr);
> if (ret)
> goto out;
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index e6bff960..f1d7160 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -17,6 +17,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> const struct kexec_file_ops * const kexec_file_loaders[] = {
> _elf64_ops,
> @@ -24,6 +26,247 @@ const struct kexec_file_ops * const kexec_file_loaders[]
> = {
> };
>
> /**
> + * get_exclude_memory_ranges - Get exclude memory ranges. This list includes
> + * regions like opal/rtas, tce-table, initrd,
> + * kernel, htab which should be avoided while
> + * setting up kexec load segments.
> + * @mem_ranges:Range list to add the memory ranges to.
> + *
> + * Returns 0 on success, negative errno on error.
> + */
> +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges)
Is it needed? See the comment below.
> +{
> + int ret;
> +
> + ret = add_tce_mem_ranges(mem_ranges);
> + if (ret)
> + goto out;
> +
> +
