[PATCH] Load crash kernel high on x86
Minfei Huang
mhuang at redhat.com
Fri Sep 18 07:03:44 PDT 2015
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).
KEXEC always use a pair of crashk_res.start and crashk_res.end as crash
memory region in kernel. And this struct is assigned in function
reserve_crashkernel during booting. In order to solve low memory issue,
there is another struct crashk_low_res is used.
So, the code flow deals with the above case correctly.
Thanks
Minfei
More information about the kexec
mailing list