On Mon, Jul 01, 2013 at 08:00:06PM -0500, Scott Wood wrote:

On 06/30/2013 02:35:21 AM, Kevin Hao wrote:

quoted

On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:

quoted

On 06/26/2013 09:00:34 PM, Kevin Hao wrote:

quoted

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.

quoted

quoted

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.

quoted

quoted

quoted

+	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@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