From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pa0-f46.google.com ([209.85.220.46]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wps8c-0005Fr-DG for kexec@lists.infradead.org; Thu, 29 May 2014 04:40:23 +0000 Received: by mail-pa0-f46.google.com with SMTP id kq14so12097480pab.5 for ; Wed, 28 May 2014 21:39:58 -0700 (PDT) Message-ID: <5386BA17.3080109@linaro.org> Date: Thu, 29 May 2014 13:39:51 +0900 From: AKASHI Takahiro MIME-Version: 1.0 Subject: Re: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid References: <1400464443-34816-1-git-send-email-wangnan0@huawei.com> <20140519160947.GM15130@arm.com> <537ACA76.3090700@huawei.com> In-Reply-To: <537ACA76.3090700@huawei.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Wang Nan , Will Deacon Cc: "linux@arm.linux.org.uk" , "kexec@lists.infradead.org" , Geng Hui , Simon Horman , Andrew Morton , "linux-arm-kernel@lists.infradead.org" Wang, Will I'm now working on kdump support for arm64 on top of Geoff's kexec patch. On 05/20/2014 12:22 PM, Wang Nan wrote: > On 2014/5/20 0:09, Will Deacon wrote: >> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote: >>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents >>> the second kernel ioremap first kernel's memory if the address falls >>> into second kernel section. This limitation requires the second kernel >>> occupies a full section, and elfcorehdr must resides in another section. >>> >>> This patch makes crash dump kernel use strict pfn_valid, removes such >>> limitation. >>> >>> For example: >>> >>> For a platform with SECTION_SIZE_BITS == 28 (256MiB) and >>> crashkernel=128M@0x28000000 in kernel cmdline, the second >>> kernel is loaded at 0x28000000. Kexec puts elfcorehdr at >>> 0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to >>> second kernel. When second kernel start, it tries to use >>> ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the >>> same section of the second kernel, pfn_valid will recongnize >>> the page as valid, so ioremap will refuse to map it. >> >> So isn't the issue here that you're passing an incorrect mem= parameter >> to the crash kernel? >> > > mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size > of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect > crashkernel= parameter? Just FYI, kexec-tools doesn't seem to be implemented in proper way to support device-tree. Once device-tree is handled correctly, we don't need to pass "mem=" parameter. (Of course, only on machines that support device-tree.) > I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM > enabled, and show how *impractical* the 'correct' crashkernel will be. > > Use realview board for example. > > Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB). > > This is because zImage determine final kernel address by (pc & 0xf8000000). If, > for example, set crashkernel=64M@0x29000000, then the second kernel itself > overwrites first kernel's memory. We'll lost some memory in /proc/vmcore. > > Limitation 2: crash kernel must resides in different section with the first kernel. > > This is because the second kernel use ioremap for accessing first kernel's memory, > and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved > for the secton kernel. On realview, which is 256MiB. > > Limitation 3: the last 1MiB of reserved memory must be ioremappable. > > This is because the second kernel depeneds kexec-tools passing an elfheader as > 'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools > simply uses the last 1MiB for it. The second kernel use ioremap to access it, force > the header be put in another section. We can avoid "Limitation 3" just by implementing arm's own elfcorehdr_read() with memcpy(). I can submit a patch, but can't test it for now. -Takahiro AKASHI > In realview board, the only possible correct setting should be 'crashkernel=257M@0x20000000'. > However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even > set this parameter, crash kernel is still unusable because: > > crashkernel reservation failed - memory is in use (0x20000000) > >> Will >> > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec