From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A57DDECAAD1 for ; Thu, 1 Sep 2022 07:26:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=sImTFv5WdrZFNCvaQgt4FtA4e2D5+LFOcIQFTpTIWGo=; b=Zj8G3RbrjQKH/Y rjTK2nMb5I0H6S7BM1mmfc4YvNpSIf74B/j74WC7TCH6pTcfEBYZ4asWlmcmwy8UxyJTdfFLyeBSh 3P+HDfp8qcUCwM111HvAz+HVgO0FRF87VCpsms82kG7xB5Jax9MzgvbVq0L/2iDajkke96/E9my7V tyHNfqmzBPrbkWAkVd7UAKZumrILat6aglWepZzz/Pg81mr/NPXaUwNR9QkLL7MfyMl2MZr3PnmiR oU0VI9BPiJhlGi4ATXbW67KEm+dg7GMPWKue5f38/fB6LSnpMhqCWtFdJnPrxhAYUTEtwEL0/+Kd/ 4LVaq2xw1cpmmDDUC2gQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTea0-00AIEr-60; Thu, 01 Sep 2022 07:25:36 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTeZr-00AI73-EW; Thu, 01 Sep 2022 07:25:29 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 61C9ECE227B; Thu, 1 Sep 2022 07:25:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3F13C433C1; Thu, 1 Sep 2022 07:25:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662017117; bh=wFBxgLE3ZKENwiyGQvZkmf0lQ+nkRd9E9wQrdKxQ/pw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Nx+Vz2yadBlXqmB6mN0pWinuEwxeVrsKNBWvD2k0uXISs3cAMKJhrrCZmZEs6gu31 hYnTLg8w3rxCg8EtPBH/PCVvX+tGAU8LPYyLD3GyyZp6vGjULev/k40TaOSbXWMr3Z jLUgV6aDdN4jifZ4BjpI0kHDwTQOUHe1GN1MznmfXdNVwXmk0U94fH6jjnj0MH5mPE uzB7AClQ26HdjHL8GdHq54asN0puEwicseuMkKbL0G7uW4KFJjk+oxddovX+FwBr4Z 9MVTdOTJ/ATlVrqMU9Mh4fUemQ4kEtEFColcwKWqiVNxXMWxq9YhFjjdebynIygckr vG0iaJFB2ZrLg== Date: Thu, 1 Sep 2022 10:24:59 +0300 From: Mike Rapoport To: Baoquan He Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, ardb@kernel.org, guanghuifeng@linux.alibaba.com, mark.rutland@arm.com, will@kernel.org, linux-mm@kvack.org, thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com, kexec@lists.infradead.org Subject: Re: [PATCH 1/2] arm64, kdump: enforce to take 4G as the crashkernel low memory end Message-ID: References: <20220828005545.94389-1-bhe@redhat.com> <20220828005545.94389-2-bhe@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_002527_885957_7E1C5B33 X-CRM114-Status: GOOD ( 37.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 31, 2022 at 10:29:39PM +0800, Baoquan He wrote: > On 08/31/22 at 10:37am, Mike Rapoport wrote: > > On Sun, Aug 28, 2022 at 08:55:44AM +0800, Baoquan He wrote: > > > > > > Solution: > > > ========= > > > To fix the problem, we should always take 4G as the crashkernel low > > > memory end in case CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled. > > > With this, we don't need to defer the crashkernel reservation till > > > bootmem_init() is called to set the arm64_dma_phys_limit. As long as > > > memblock init is done, we can conclude what is the upper limit of low > > > memory zone. > > > > > > 1) both CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 are disabled or memblock_start_of_DRAM() > 4G > > > limit = PHYS_ADDR_MAX+1 (Corner cases) > > > > Why these are corner cases? > > The case when CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 are disabled is the > > simplest one because it does not require the whole dancing around > > arm64_dma_phys_limit initialization. > > > > And AFAIK, memblock_start_of_DRAM() > 4G is not uncommon on arm64, but it > > does not matter for device DMA addressing. > > Thanks for reviewing. > > I could be wrong and have misunderstanding about corner case. > > With my understanding, both ZONE_DMA and ZONE_DMA32 are enabled by > default in kernel. And on distros, I believe they are on too. The both > ZONE_DMA and ZONE_DMA32 disabled case should only exist on one specific > product, and the memblock_start_of_DRAM() > 4G case too. At least, I > haven't seen one in our LAB. What I thought the non generic as corner > case could be wrong. I will change that phrasing. > > mm/Kconfig: > config ZONE_DMA > bool "Support DMA zone" if ARCH_HAS_ZONE_DMA_SET > default y if ARM64 || X86 > > config ZONE_DMA32 > bool "Support DMA32 zone" if ARCH_HAS_ZONE_DMA_SET > depends on !X86_32 > default y if ARM64 My point was that the cases with ZONE_DMA/DMA32 disabled or with RAM above 4G do not require detection of arm64_dma_phys_limit before reserving the crash kernel, can use predefined constants and are simple to handle. > > The actual corner cases are systems with ZONE_DMA/DMA32 and with <32 bits > > limit for device DMA addressing (e.g RPi 4). I think the changelog should > > Right, RPi4's 30bit DMA addressing device is corner case. > > > mention that to use kdump on these devices user must specify > > crashkernel=X@Y > > Makes sense. I will add words in log, and add sentences to > mention that in code comment or some place of document. > Thanks for advice. > > > > > > 2) CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 are enabled: > > > limit = 4G (generic case) > > > ... > > > +static phys_addr_t __init crash_addr_low_max(void) > > > +{ > > > + phys_addr_t low_mem_mask = U32_MAX; > > > + phys_addr_t phys_start = memblock_start_of_DRAM(); > > > + > > > + if ((!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) || > > > + (phys_start > U32_MAX)) > > > + low_mem_mask = PHYS_ADDR_MAX; > > > + > > > + return min(low_mem_mask, memblock_end_of_DRAM() - 1) + 1; > > > > Since RAM frequently starts on non-zero address the limit for systems with > > ZONE_DMA/DMA32 should be memblock_start_of_DRAM() + 4G. There is no need to > > It may not be right for memblock_start_of_DRAM(). On most of arm64 > servers I ever tested, their memblock usually starts from a higher > address, but not zero which is like x86. E.g below memory ranges printed > on an ampere-mtsnow-altra system, the starting addr is 0x83000000. With > my understanding, DMA addressing bits correspond to the cpu logical > address range devices can address. So memblock_start_of_DRAM() + 4G > seems not right for normal system, and not right for system which > starting physical address is above 4G. I refer to max_zone_phys() of > arch/arm64/mm/init.c when implementing crash_addr_low_max(). Please > correct me if I am wrong. My understanding was that no matter where DRAM starts, the first 4G would be accessible by 32-bit devices, but I maybe wrong as well :) I haven't notice you used max_zone_phys() as a reference. Wouldn't it be simpler to just call it from crash_addr_low_max(): static phys_addr_t __init crash_addr_low_max(void) { return max_zone_phys(32); } -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel