[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for the crash kernel



>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>causes an exact size and location to be reserved in the e820 map
>before Xen and modules are relocated.  However, using "new" syntax
>(<start>-[<end>]:<size>) encounteres a myriad of problems, most
>notibly not considering the range when allocating its region.

I'm sure I tested this (with some basic values), so the "myriad of
problems" make me curious as to what they are.

What does "range" refer to here, and what is "its region"?

You also seem to overlook that even the old syntax allowed for only
specifying a size.

>This patch tries to unify both codepaths, and fix the broken logic
>when using "newer" syntax.
>
>Changes addressed:
>
>1) Remove use of kexec_crash_area from parse_crashkernel().
>     Use ranges[0] in preference, as there is no support for multiple
>     ranges using classic syntax.  This prevents some wierd logic in
>     __setup_xen() depending on whether kexec_crash_area.size is set
>     or not.

What weird about that?

>2) Change set_kexec_crash_area_size() to choose_kexec_range()
>     The new method of choosing a range provides an entire rather than

And entire what?

>     just setting kexec_crash_area.size.  Also, fix the very broken
>     logic which will only consider a range if its .end is greater
>     than system_ram.

Where's that happening? Are you perhaps mis-interpreting the
purpose of these ranges?

>  Additionally, prefer range with the largest
>     size if we have a choice of valid ones, and prefer ranges with
>     more flexibility in their limits.
>
>3) Move kexec_reserve_area() from setup.c to kexec.c
>     It makes more sense here, Also, change its functionality a little
>     to always work from the kexec range provided by choose_kexec_range()
>
>4) Remove the kexec reservation code when considering modules
>     This code only had any effect for people using the "newer" syntax
>     on the command line, as people using the "classic" syntax would
>     reserve a memory region before considering modules.

Are you sure? How do you prevent the kexec area from overlapping
any of the modules (in particular the initrd, which can get passed in
place to Dom0)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.