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@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
pgpi7GUVWHOV7.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
