From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pratyush Anand Subject: Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t Date: Tue, 3 May 2016 11:23:29 +0530 Message-ID: <20160503055329.GA13045@dhcppc6.redhat.com> References: <20160428092644.GX19428@n2100.arm.linux.org.uk> <20160429151639.GC23726@leverpostej> <20160503042441.GA2518@x1.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20160503042441.GA2518@x1.redhat.com> Sender: linux-ia64-owner@vger.kernel.org To: Baoquan He Cc: Russell King , Mark Rutland , devicetree@vger.kernel.org, Ian Campbell , Tony Luck , linux-ia64@vger.kernel.org, Pawel Moll , linux-doc@vger.kernel.org, Jonathan Corbet , kexec@lists.infradead.org, Fenghua Yu , Vivek Goyal , Haren Myneni , Rob Herring , Eric Biederman , Santosh Shilimkar , Kumar Gala , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org Hi Baoquan, On 03/05/2016:12:24:41 PM, Baoquan He wrote: > Hi Pratyush, > > Could you please help tell why arm PAE kernel can be put above 4G? PAE system can have physical addresses above 4G. So, if a CPU is supporting the LPAE page table format then we should be able to access physical addresses beyond 4G. > Since the change is related to common code, I am curious about how > it's so different with other ARCHs. paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t seems most appropriate. So, kernel variable may land into above 4G locations, even with the platform in other architecture (with PAE support), if start of RAM is located very high, So, in my opinion it would be safer to have these changes for other ARCHs as well. ~Pratyush