From: Scott Wood <scottwood@freescale•com>
To: Kevin Hao <haokexin@gmail•com>
Cc: linuxppc <linuxppc-dev@lists•ozlabs.org>
Subject: Re: [PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel
Date: Mon, 1 Jul 2013 20:00:06 -0500 [thread overview]
Message-ID: <1372726806.8183.105@snotra> (raw)
In-Reply-To: <20130630073521.GC32268@pek-khao-d1.corp.ad.wrs.com> (from haokexin@gmail.com on Sun Jun 30 02:35:21 2013)
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.
>=20
> This is not for the hardware limitation.
It's not for a general software limitation, either. We can use 1G =20
mappings for user hugetlb (if the default mmap address is moved out of =20
the way) or for the kernel lowmem mapping (if the address is moved to =20
0x80000000 instead of 0xc0000000).
It's also possible (although unlikely at this point) that someone could =20
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?
>=20
> 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 =3D calc_cam_sz(ram, virt, phys);
> > >+ if (cam_sz + phys > PHYSICAL_START + _end - _stext)
> > >+ break;
> > >+ ram =3D 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.
>=20
> 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 =20
(if it is, could you point out where?), you'd then have a problem with =20
the crashkernel area going anywhere above 256M.
-Scott=
next prev parent reply other threads:[~2013-07-02 1:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 2:00 [PATCH 0/2] powerpc: enable the relocatable support for fsl booke 32bit kernel Kevin Hao
2013-06-27 2:00 ` [PATCH 1/2] powerpc: enable the relocatable support for the " Kevin Hao
2013-06-27 19:58 ` Scott Wood
2013-06-28 1:36 ` Kevin Hao
2013-06-28 1:47 ` Scott Wood
2013-06-30 7:33 ` Kevin Hao
2013-07-02 0:30 ` Scott Wood
2013-07-02 3:24 ` Kevin Hao
2013-07-02 22:39 ` Scott Wood
2013-07-03 3:00 ` Kevin Hao
2013-07-03 20:38 ` Scott Wood
2013-07-04 1:08 ` Kevin Hao
2013-07-08 16:48 ` Scott Wood
2013-07-09 1:26 ` Kevin Hao
2013-06-28 1:52 ` Scott Wood
2013-06-30 7:34 ` Kevin Hao
2013-06-27 2:00 ` [PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel Kevin Hao
2013-06-28 2:19 ` Scott Wood
2013-06-30 7:35 ` Kevin Hao
2013-07-02 1:00 ` Scott Wood [this message]
2013-07-02 3:45 ` Kevin Hao
2013-07-02 22:41 ` Scott Wood
2013-07-03 3:29 ` Kevin Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1372726806.8183.105@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=haokexin@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox