aboutsummaryrefslogtreecommitdiffstats
path: root/xen/common
diff options
context:
space:
mode:
authorIan Campbell <ian.campbell@xensource.com>2007-01-12 16:03:33 +0000
committerIan Campbell <ian.campbell@xensource.com>2007-01-12 16:03:33 +0000
commitc59635dc0f2f1201fa56231143959a03587c9890 (patch)
tree907a113a88b850760790affadf3885ad6b7414ad /xen/common
parent87f272150c7bffd0166abd97b166e474f79109a9 (diff)
downloadxen-c59635dc0f2f1201fa56231143959a03587c9890.tar.gz
xen-c59635dc0f2f1201fa56231143959a03587c9890.tar.bz2
xen-c59635dc0f2f1201fa56231143959a03587c9890.zip
[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@verge.net.au>
Diffstat (limited to 'xen/common')
-rw-r--r--xen/common/kexec.c22
1 files changed, 8 insertions, 14 deletions
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 294e57b353..e0708ac7c9 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -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;
}