# HG changeset patch
# User Ian Campbell <ian.campbell@xxxxxxxxxxxxx>
# Date 1168617813 0
# Node ID 819e9449db07daa1d8498bf3c3d176e2f108628a
# Parent c149ffa2fd1a0517d5e020d5c65e49413009d079
[PATCH] kexec/kdump: allow zero start for crashkernel
Some architectures, notably ia64, can automatically place
the crash kernel into an appropriate place if the start
address for crashkernel is specified as zero or omitted.
E.g. crashkernel=256M or crashkernel=256M@0
While xen does not actually have support for ia64 kexec,
I am working on it. And in any case this change should be harmless.
Just a small bit of infastructure that will make things easier in the
future.
This should also be possible on x86, now relocatable kernels
are reloacatble on x86. So once xen moves up to using linux ~2.6.19
it would make sense to look into implementing this.
The patch does 3 things.
* Firstly, parse_crashkernel() is modified to allows the size and start
elements of kexec_crash_area
to be set to any value, including zero. Previously if either size or
start were specified as zero, they would both end up as zero.
* Secondly, when kexec_get() is called, if either the size or start
elements of kexec_crash_area are zero, then zero is passed
back to the hypercall caller for both values.
This gives the same behaviour as having parse_crashkernel() set
size and start to zero if either of them are zero, but it allows
architecture sepcific code called between the invocation of
parse_crashkernel() and kexec_get() to modify start (and size if
there was a reason). In particular, this allows the
architecture specific code to find a good start point if 0 is
specified.
* Lastly, it ads an additional check to the x86 setup code.
As this code currently does not know how to deal with a
0 start address, it doesn't reserve memory if start is 0.
This is neccessary as previously if start was specified as zero,
parse_crashkernel() would set size to zero, but that is
no longer the case, so a stronger check is needed.
I would really appreciate it if this patch was merged,
as I don't believe it harms anything, and it does allow
a nice path for moving forwards.
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
---
xen/arch/x86/setup.c | 2 +-
xen/common/kexec.c | 22 ++++++++--------------
2 files changed, 9 insertions(+), 15 deletions(-)
diff -r c149ffa2fd1a -r 819e9449db07 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c Fri Jan 12 15:35:52 2007 +0000
+++ b/xen/arch/x86/setup.c Fri Jan 12 16:03:33 2007 +0000
@@ -486,7 +486,7 @@ void __init __start_xen(multiboot_info_t
#endif
}
- if ( kexec_crash_area.size > 0 )
+ if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0)
{
unsigned long kdump_start, kdump_size, k;
diff -r c149ffa2fd1a -r 819e9449db07 xen/common/kexec.c
--- a/xen/common/kexec.c Fri Jan 12 15:35:52 2007 +0000
+++ b/xen/common/kexec.c Fri Jan 12 16:03:33 2007 +0000
@@ -51,19 +51,9 @@ xen_kexec_reserve_t kexec_crash_area;
static void __init parse_crashkernel(const char *str)
{
- unsigned long start, size;
-
- size = parse_size_and_unit(str, &str);
+ kexec_crash_area.size = parse_size_and_unit(str, &str);
if ( *str == '@' )
- start = parse_size_and_unit(str+1, NULL);
- else
- start = 0;
-
- if ( start && size )
- {
- kexec_crash_area.start = start;
- kexec_crash_area.size = size;
- }
+ kexec_crash_area.start = parse_size_and_unit(str+1, NULL);
}
custom_param("crashkernel", parse_crashkernel);
@@ -158,8 +148,12 @@ static void setup_note(Elf_Note *n, cons
static int kexec_get(reserve)(xen_kexec_range_t *range)
{
- range->start = kexec_crash_area.start;
- range->size = kexec_crash_area.size;
+ if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
+ range->start = kexec_crash_area.start;
+ range->size = kexec_crash_area.size;
+ }
+ else
+ range->start = range->size = 0;
return 0;
}
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
Home