On 09/18/15 at 10:40am, Petr Tesarik wrote:
> On Fri, 18 Sep 2015 08:03:24 +0200
> Petr Tesarik <ptesarik at suse.com> wrote:
>
> > Hello,
> >
> > There may be more than one crash kernel regions on x86. However, the kexec
> > syscall checks that target address is within crashk_res boundaries. Looking
> > at the logic in arch/x86/kernel/setup.c, there are only two possible layouts:
> >
> > 1. crashk_res is below 4G, and there is only one region,
> > 2. crashk_res is above 4G, and crashk_low_res is below 4G
> >
> > In either case, kexec-tools must pick the highest region.
> >
> > Currently, kexec-tools picks the largest region. If high reservation is
> > smaller than low, kexec(2) returns -EADDRNOTAVAIL, and kexec prints out
> > this error message:
> >
> > kexec_load failed: Cannot assign requested address
>
> I have just re-checked with kexec_file(2), and it is also affected. At
> this point, you may think that it would be better to fix the check in
> sanity_check_segment_list() instead.
>
> I don't think so.
>
> Low memory reservation is intended for swiotlb and DMA buffers, i.e. it
> is somehow precious. The kernel can run above 4G, initrd can also be
> located above 4G, so why should I place it in the _precious_ low memory?
>
> If you agree, I'll also post a kernel patch for kexec_file(2).
It does not need a fix in kernel for kexec_file. Since it uses below code
to get memory in kexec_add_buffer(), this is the same as it does in
locate_hole() using mem_min and mem_max in kexec_tools.
/* Walk the RAM ranges and allocate a suitable range for the buffer */
if (image->type == KEXEC_TYPE_CRASH)
ret = walk_iomem_res("Crash kernel",
IORESOURCE_MEM | IORESOURCE_BUSY,
crashk_res.start, crashk_res.end, kbuf,
locate_mem_hole_callback);
else
...
Thanks
Baoquan
