Re: [PATCH] powerpc: check crash_base for relocatable kernel

[Milton Miller <miltonm@bga.com>]

[removed Paul from cc and fixed Mohan's email]

On Jan 6, 2009, at 5:44 PM, Michael Ellerman wrote:

> On Fri, 2009-01-02 at 14:46 -0600, Milton Miller wrote:
>> @@ -94,10 +95,35 @@ void __init reserve_crashkernel(void)
>>  				KDUMP_KERNELBASE);
>>
>>  	crashk_res.start = KDUMP_KERNELBASE;
>> +#else
>> +	if (!crashk_res.start) {
>> +		/*
>> +		 * unspecified address, choose a region of specified size
>> +		 * can overlap with initrd (ignoring corruption when retained)
>> +		 * ppc64 requires kernel and some stacks to be in first segemnt
>> +		 */
>> +		crashk_res.start = KDUMP_KERNELBASE;
>> +	}
>> +
>> +	crash_base = PAGE_ALIGN(crashk_res.start);
>> +	if (crash_base != crashk_res.start) {
>> +		printk("Crash kernel base must be aligned to 0x%lx\n",
>> +				PAGE_SIZE);
>> +		crashk_res.start = crash_base;
>> +	}
>> +
>>  #endif
>>  	crash_size = PAGE_ALIGN(crash_size);
>>  	crashk_res.end = crashk_res.start + crash_size - 1;
>>
>> +	/* The crash region must not overlap the current kernel */
>> +	if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
>> +		printk(KERN_WARNING
>> +			"Crash kernel can not overlap current kernel\n");
>> +		crashk_res.start = crashk_res.end = 0;
>> +		return;
>> +	}
>
> I think we can be smarter here. Why don't we adjust the crash kernel
> region so that it doesn't overlap the first kernel? ie. move it up a
> bit.

How much?   In addition to the size of the kernel, we have to allocate 
(1) the emergeency stacks as we use them to bring up secondary cpus (2) 
the irq stacks in the first segment.   While the second could be met 
easier on systems with 1TB slbs we don't take advantage of that yet.


>
> There's also the issue of the RMO, I'm not sure what we should do 
> there,
> but I think the kernel needs some smarts otherwise users are going to
> shoot themselves in the foot.

I was looking at the code in kexec-tools for the rmo, and it seems 
extremely broken (ie it sets rmo_top on every memory block instead of 
the lowest; the clamp to 768M is the savior for systems with multiple 
blocks).

Do we care about loading a kernel below a relocated kernel (between the 
interrupt vectors and the new kernel)?   I ignored that for now, 
arguing that we always run the first kernel at 0.


>
> We could ignore the @x setting and split the RMO between both kernels
> somewhat intelligently.
>
> What might work is multiple crash regions, that way we could have some
> space in the RMO for the second kernel (say 32MB?), but the rest 
> outside
> - leaving some RMO for the first kernel. But I think that would require
> some serious surgery.
>

Other archs have this, i guess because they read the memory out of 
/proc/iomem.   The trick is knowing what has to be put in real space 
and what can go abvoe the rmo.   Also, we have those horrible hard-code 
rmo to 768M max because some platform (one of the cell ones?) didn't 
make the device tree to show it.  Maybe we can track it down and add 
linux,usable-mem-ranges to fix it up?

Does the generic code support loading into the split regions, or is it 
just for giving the kernel room to run?



So while all of these are nice, what do you think about merging this as 
an interm measure, especially for backporting to 2.6.28 stable (and any 
distro that wants to pick up relocatable kdump)?

milton


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec