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

[Scott Wood]

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.

> > 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?

> > >+	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?), you'd then have a problem with  
the crashkernel area going anywhere above 256M.

-Scott