[PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel

[Kevin Hao]

On Mon, Jul 01, 2013 at 08:00:06PM -0500, Scott Wood wrote:
> On 06/30/2013 02:35:21 AM, Kevin Hao wrote:
> >On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:
> >> On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> >> >diff --git a/arch/powerpc/include/asm/mmu-book3e.h
> >> >b/arch/powerpc/include/asm/mmu-book3e.h
> >> >index 936db36..bf422db 100644
> >> >--- a/arch/powerpc/include/asm/mmu-book3e.h
> >> >+++ b/arch/powerpc/include/asm/mmu-book3e.h
> >> >@@ -214,6 +214,11 @@
> >> > #define TLBILX_T_CLASS2			6
> >> > #define TLBILX_T_CLASS3			7
> >> >
> >> >+#ifdef CONFIG_PPC32
> >> >+/* The max size that one tlb can map in a 32bit kernel. */
> >> >+#define PPC_PIN_SIZE	(1 << 28)	/* 256M */
> >> >+#endif
> >>
> >> That comment is not true for all chips.
> >
> >This is not for the hardware limitation.
> 
> It's not for a general software limitation, either.  We can use 1G
> mappings for user hugetlb (if the default mmap address is moved out
> of the way) or for the kernel lowmem mapping (if the address is
> moved to 0x80000000 instead of 0xc0000000).
> 
> It's also possible (although unlikely at this point) that someone
> could make a 32-bit booke chip that cannot handle 256M mappings.

Then I have to agree with you. :-)
Wish I can find a way to drop it.

> 
> >> Pardon my ignorance about how kdump/kexec works, but I'm a bit
> >> confused by exactly what the situation is with crashkernel.  How do
> >> we know that we are the crash kernel, and that we should limit our
> >> RAM usage to that area?
> >
> >The kexec tool will parse the command line of the boot kernel and get
> >the reserved memory info (such as start address, size) and then pass
> >these informations to the kdump kernel via device tree.
> 
> Does this alter memstart_addr or just mark the region as reserved?

This will alter memstart_addr since we set memstart_addr based on the
memory node in device tree.

> 
> >> >+	while (1) {
> >> >+		cam_sz = calc_cam_sz(ram, virt, phys);
> >> >+		if (cam_sz + phys > PHYSICAL_START + _end - _stext)
> >> >+			break;
> >> >+		ram = 1 << (ilog2(ram) + 1);
> >> >+	}
> >>
> >> The ram that was passed in is as much as you have.  Don't map more.
> >>
> >> What happens if (e.g.) memstart_addr is 512M, with a size of 512M,
> >> and the kernel starts at 768M?  Increasing the size will never get
> >> you a mapping that covers kernstart, because calc_cam_sz will never
> >> return more than 256M.
> >
> >Yes, the current code still can't handle this case. We always assume
> >that the kernel is in the memory region which can be covered by the
> >first tlb entry.
> 
> Assuming memstart_addr isn't affected by the crashkernel reservation
> (if it is, could you point out where?),

No. The memstart_addr does be affected. For example, for a boot kernel
with the command line with "crashkernel=32M at 64M", the device tree passed
the kdump kernel will have a memory node like this:
    memory {
            reg = <0x0 0x4000000 0x0 0x2000000>;
            device_type = "memory";
    }

Then the memstart_addr will be set to 0x4000000 in the kdump kernel.

> you'd then have a problem
> with the crashkernel area going anywhere above 256M.

The kdump kernel can be loaded above 256M memory. It only can not be loaded
above memstart_addr + 256M memory.

Thanks,
Kevin

> 
> -Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20130702/6920467f/attachment-0001.sig>