[PATCH] kexec/kdump: allow zero start for crashkernel
authorIan Campbell <ian.campbell@xensource.com>
Fri, 12 Jan 2007 16:03:33 +0000 (16:03 +0000)
committerIan Campbell <ian.campbell@xensource.com>
Fri, 12 Jan 2007 16:03:33 +0000 (16:03 +0000)
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@verge.net.au>
xen/arch/x86/setup.c
xen/common/kexec.c

index 8770a2950923561eea8fc9b7273b0240818abb99..5b46c4685e18c8f5d9f64ea4cb75afedf4791c45 100644 (file)
@@ -486,7 +486,7 @@ void __init __start_xen(multiboot_info_t *mbi)
 #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;
 
index 294e57b35359cb8d0a8c017fad11f19d33f68204..e0708ac7c92ca6076e7acc03bd26e55e8043ba0d 100644 (file)
@@ -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, const char *name, int type, int descsz)
 
 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;
 }