From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1as7M8-0000Ls-BU for kexec@lists.infradead.org; Mon, 18 Apr 2016 11:28:40 +0000 Date: Mon, 18 Apr 2016 19:28:15 +0800 From: Baoquan He Subject: Re: [PATCH 3/3] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t Message-ID: <20160418112815.GF3602@x1.redhat.com> References: <20160414195938.GV19428@n2100.arm.linux.org.uk> <20160418053820.GC3602@x1.redhat.com> <20160418083601.GY19428@n2100.arm.linux.org.uk> <20160418103258.GE3602@x1.redhat.com> <20160418105236.GB19428@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160418105236.GB19428@n2100.arm.linux.org.uk> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Russell King - ARM Linux Cc: Fenghua Yu , Tony Luck , linux-ia64@vger.kernel.org, Eric Biederman , kexec@lists.infradead.org On 04/18/16 at 11:52am, Russell King - ARM Linux wrote: > On Mon, Apr 18, 2016 at 06:32:58PM +0800, Baoquan He wrote: > > On 04/18/16 at 09:36am, Russell King - ARM Linux wrote: > > > On Mon, Apr 18, 2016 at 01:38:20PM +0800, Baoquan He wrote: > > > > On 04/14/16 at 09:00pm, Russell King wrote: > > > > > On PAE systems (eg, ARM LPAE) the vmcore note may be located above > > > > > 4GB physical on 32-bit architectures, so we need a wider type than > > > > > "unsigned long" here. Arrange for paddr_vmcoreinfo_note() to return > > > > > a phys_addr_t, thereby allowing it to be located above 4GB. > > > > > > > > At first glance, it sounds great. But I can't imagine a scenario where > > > > on pae system kernel can be located above 4G. As far as I know i386 and > > > > its pae can't do this because the current linux VM implementation can't > > > > allow that. I am not familiar with arm system. So please correct me if > > > > I was wrong. > > > > > > You are wrong. That's precisely why this patch exists. > > > > I don't know arm is different then i386. On i386 the kernel text mapping > > is linear, just as follow: > > > > #define __phys_addr_nodebug(x) ((x) - PAGE_OFFSET) > > > > > > But arm seems not linear. > > static inline phys_addr_t __virt_to_phys(unsigned long x) > > { > > phys_addr_t t; > > > > if (sizeof(phys_addr_t) == 4) { > > __pv_stub(x, t, "add", __PV_BITS_31_24); > > } else { > > __pv_stub_mov_hi(t); > > __pv_add_carry_stub(x, t); > > } > > return t; > > } > > > > So on arm PAE this change makes sense. > > No. This has nothing to do with whether memory is linear or not. The > above code has nothing to do with that either. The above code you quote > allows us to efficiently runtime modify the virtual to physical > translation offset, nothing more. OK, thanks for telling this. Learned it. > > > Besides, I checked kexec/arch/arm/kexec-zImage-arm.c and found function > > locate_hole() is used to find position for arm kernel. > > > > unsigned long locate_hole(struct kexec_info *info, > > unsigned long hole_size, unsigned long hole_align, > > unsigned long hole_min, unsigned long hole_max, > > int hole_end) > > > > The type unsigned long for hole_max limit the region where arm kernel is > > loaded. So withough modifying this I doubt arm PAE can really be loaded > > above 4G. > > Please, stop "doubting" the patches. > > I have here a machine which requires these patches, and they're all > tested. Without these patches, it doesn't work - and in fact trying > to use kexec on the platform takes out userspace due to the OOM killer. > With these patches, it does work - fully. It has the start of system > memory above 4GB physical, with a non-DMA coherent boot time alias > below 4GB. > > On a running system, the kernel ignores the boot alias below 4GB. > Having discussed with Eric, kexec is designed to use the boot time > alias, and we need to teach kexec about the difference between the > boot time alias and the running system memory layout. > > That's what these patches are all about. > > I've been discussing the problem with Eric on and off over the last > six months, and he's the one who suggested in part the solution > implemented in this series. Got it. Just pass by to have a look:) Since Erci suggested these I stop making noise right now. Thanks for telling above knowledge about arm. Thanks Baoquan _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec