Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755746AbcJNDgu (ORCPT ); Thu, 13 Oct 2016 23:36:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38964 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753761AbcJNDgt (ORCPT ); Thu, 13 Oct 2016 23:36:49 -0400 Date: Fri, 14 Oct 2016 11:13:04 +0800 From: Dave Young To: Baoquan He , ats-kumagai@wm.jp.nec.com Cc: Pratyush Anand , keescook@chromium.org, ats-kumagai@wm.jp.nec.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, thgarnie@google.com, takahiro.akashi@linaro.org, mingo@redhat.com, "Eric W. Biederman" , hpa@zytor.com, tglx@linutronix.de, akpm@linux-foundation.org, tonli@redhat.com Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo Message-ID: <20161014031304.GA3483@dhcp-128-65.nay.redhat.com> References: <1475743561-23912-1-git-send-email-bhe@redhat.com> <877f9lckbq.fsf@x220.int.ebiederm.org> <20161011074111.GD11185@x1> <20161011081921.GA21765@dhcp-128-65.nay.redhat.com> <20161012002613.GB21477@x1> <256e8ba2-4f92-36cf-ec5c-2502113922c6@redhat.com> <20161013085314.GF11185@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161013085314.GF11185@x1> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 14 Oct 2016 03:13:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2358 Lines: 63 On 10/13/16 at 04:53pm, Baoquan He wrote: > Hi Pratyush, > > On 10/12/16 at 02:39pm, Pratyush Anand wrote: > > > > > > On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote: > > > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only > > > > > VMALLOC_BASE and VMEMMAP_BASE is necessary.. > > > Well, yes, I was wrong. I wrongly thought of kernel text virtual address > > > when I wrote the reply > > > > So, if you can get PAGE_OFFSET then, probably you do not need to know > > anything else. > > > > I think, we can simplify makedumpfile code, where we do not need to depend > > on VMALLOC_START or VMEMMAP_START etc. > > > > "If we know PAGE_OFFSET, we can read from swapper space. If we can read from > > swapper space, then we can know PA of any kernel VA, whether it is VMALLOC, > > or vmemmap or module or kernel text area." > > Check makedumpfile code and re-think about this, it's really like you > said, we can convert VA to PA by swapper_pg_dir or init_level4_pgt. But the > reason why we have to involve VMALLOC_START and VMEMMAP_START is that in > x86_64 direct mapping and kernel text mapping are all linear mapping. > Linear mapping can let us do a very efficient translation from VA to > PA. Especially for page filtering, we need get PA of mm related data. > All of them need convert by swapper_pg_dir or init_level4_pgt, that's > inefficient, imagine the current system usually own many Tera bytes of > physical memory. > Atsushi, what do you think about above concern? Ideally we should do it in userspace instead of add more symbols. Maybe do a test on large memory machine is necessary. > So here though we can pick up crash memory regions from elf program > header of vmcore and calculate the PAGE_OFFSET, we still need > VMALLOC_START and VMEMMAP_START. > > Thanks > Baoquan > > > > > > In fact, I have cleanup patches for ARM64 [1], which take above approach and > > get rid of need of VMALLOC_START or VMEMMAP_START etc. I will be sending > > them upstream soon. > > > > Probably, x86 can take the similar approach. > > > > ~Pratyush > > > > [1] https://github.com/pratyushanand/makedumpfile/blob/arm64_devel/arch/arm64.c#L228 > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Thanks Dave