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 B63F4C433F5 for ; Thu, 17 Feb 2022 18:27:39 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oaPk321jxHEh1pFqpoZvbNXQ9fDM4kR5BNdJwa1M+fM=; b=nSqGrMQ/E21c5K 3va40qAoMsx1IpewSrcgC7zbKUVmAT/h4jAzgJOVno9RXZ+rnH8GryGKdcDaBjXT86S//7SnDCVNa ZD52SZ8tKgz+ZNxpmdBKeeoU8muu8WF91m/h5LB0HIwXuaFcihSCd1UvpBpWDgp1iAUxLvVaDhiKU mhcYMpP0ahUJt6V8spPk+rN5UeTW+Z5ijWEDtT4lP4mbTb9TKmbQnBX1ZQlBvNYB7BSQIv3uhu6h4 610ZcZilP86WstSi3fxmLf8rm9HdBtLecdITw48eMI0qU0aB0rc/ZXBQYrotQWAxBE9eSGBGikY8Q 2LsFBBJZrrMuYCG+dmsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKlTw-00Bj6E-W4; Thu, 17 Feb 2022 18:26:21 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKlTt-00Bj5g-NL for linux-arm-kernel@lists.infradead.org; Thu, 17 Feb 2022 18:26:19 +0000 Received: from [192.168.4.54] (cpe-70-95-196-11.san.res.rr.com [70.95.196.11]) by linux.microsoft.com (Postfix) with ESMTPSA id 6417420BE580; Thu, 17 Feb 2022 10:26:15 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6417420BE580 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1645122375; bh=M5mtPIPM0j89LYQrp63Y0RDZN8FfF+oH71W+YVr1EAg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZkSaFxck2/vs6ydzKP+M0Vwdxo3z9RLR4b/doO3dwzRWM79cluxNtJXvtFZIeh0mG OZryPCMcrDKN/rMuZNVGd2F/1wwU4zgQnn5If+KUOspP/jtbCOXH9+HTPwRzlYgFs0 P35lWg9V09Qvn1zsp5zps+G/NOArhl2Fio5iyDWo= Message-ID: Date: Thu, 17 Feb 2022 10:26:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] arm64: Do not defer reserve_crashkernel() for platforms with no DMA memory zones Content-Language: en-US To: nicolas saenz julienne , Catalin Marinas , Will Deacon Cc: Anshuman Khandual , Mike Rapoport , Ard Biesheuvel , Pavel Tatashin , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <1645056294-6509-1-git-send-email-vijayb@linux.microsoft.com> From: Vijay Balakrishna In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220217_102617_907562_E1047741 X-CRM114-Status: GOOD ( 19.10 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/17/2022 2:49 AM, nicolas saenz julienne wrote: > On Wed, 2022-02-16 at 16:04 -0800, Vijay Balakrishna wrote: >> The following patches resulted in deferring crash kernel reservation to >> mem_init(), mainly aimed at platforms with DMA memory zones (no IOMMU), >> in particular Raspberry Pi 4. >> >> commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") >> commit 8424ecdde7df ("arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges") >> commit 0a30c53573b0 ("arm64: mm: Move reserve_crashkernel() into mem_init()") .. >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index acfae9b41cc8..e7faf5edccfc 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -517,7 +517,7 @@ static void __init map_mem(pgd_t *pgdp) >> */ >> BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end)); >> >> - if (can_set_direct_map() || crash_mem_map || IS_ENABLED(CONFIG_KFENCE)) >> + if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE)) >> flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; >> >> /* >> @@ -528,6 +528,14 @@ static void __init map_mem(pgd_t *pgdp) >> */ >> memblock_mark_nomap(kernel_start, kernel_end - kernel_start); >> >> +#ifdef CONFIG_KEXEC_CORE >> + if (crash_mem_map && !crashk_res.end) >> + flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; > > Using IS_ENABLED(ZONE_DMA/DMA32) instead of '!crashk_res.end' would be more > efficient and a bit more explicit IMO. Sure, I will make change in a follow up submission. > >> /* map all the memory banks */ >> for_each_mem_range(i, &start, &end) { >> if (start >= end) >> @@ -554,6 +562,20 @@ static void __init map_mem(pgd_t *pgdp) >> __map_memblock(pgdp, kernel_start, kernel_end, >> PAGE_KERNEL, NO_CONT_MAPPINGS); >> memblock_clear_nomap(kernel_start, kernel_end - kernel_start); >> +#ifdef CONFIG_KEXEC_CORE >> + /* >> + * Use page-level mappings here so that we can shrink the region >> + * in page granularity and put back unused memory to buddy system >> + * through /sys/kernel/kexec_crash_size interface. >> + */ >> + if (crashk_res.end) { > > Same here. Yes. > >> + __map_memblock(pgdp, crashk_res.start, crashk_res.end + 1, >> + PAGE_KERNEL, >> + NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); >> + memblock_clear_nomap(crashk_res.start, >> + resource_size(&crashk_res)); >> + } >> +#endif > > Now, I carefully reviewed the patch and it seems to be doing the right thing. > But even while knowlegable on the topic, it took a good amount of effort to > untangle the possible code paths. I suspect it's going to be painful to > maintain. I'd suggest at least introducing a comment explaining the situation. I appreciate your review. Yes, it took a good amount of time for me (new here) too and glad for your notice. Let me take a shot at explaining in my next revision. > > If there approach if deemed acceptable, I'll test is on the RPi4. Please, your testing on RPi4 would be valuable. Thanks, Vijay > > Regards, > Nicolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37C0AC433EF for ; Thu, 17 Feb 2022 18:26:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244373AbiBQS0d (ORCPT ); Thu, 17 Feb 2022 13:26:33 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:41788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232414AbiBQS0b (ORCPT ); Thu, 17 Feb 2022 13:26:31 -0500 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6551A33351 for ; Thu, 17 Feb 2022 10:26:16 -0800 (PST) Received: from [192.168.4.54] (cpe-70-95-196-11.san.res.rr.com [70.95.196.11]) by linux.microsoft.com (Postfix) with ESMTPSA id 6417420BE580; Thu, 17 Feb 2022 10:26:15 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6417420BE580 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1645122375; bh=M5mtPIPM0j89LYQrp63Y0RDZN8FfF+oH71W+YVr1EAg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZkSaFxck2/vs6ydzKP+M0Vwdxo3z9RLR4b/doO3dwzRWM79cluxNtJXvtFZIeh0mG OZryPCMcrDKN/rMuZNVGd2F/1wwU4zgQnn5If+KUOspP/jtbCOXH9+HTPwRzlYgFs0 P35lWg9V09Qvn1zsp5zps+G/NOArhl2Fio5iyDWo= Message-ID: Date: Thu, 17 Feb 2022 10:26:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] arm64: Do not defer reserve_crashkernel() for platforms with no DMA memory zones Content-Language: en-US To: nicolas saenz julienne , Catalin Marinas , Will Deacon Cc: Anshuman Khandual , Mike Rapoport , Ard Biesheuvel , Pavel Tatashin , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <1645056294-6509-1-git-send-email-vijayb@linux.microsoft.com> From: Vijay Balakrishna In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/17/2022 2:49 AM, nicolas saenz julienne wrote: > On Wed, 2022-02-16 at 16:04 -0800, Vijay Balakrishna wrote: >> The following patches resulted in deferring crash kernel reservation to >> mem_init(), mainly aimed at platforms with DMA memory zones (no IOMMU), >> in particular Raspberry Pi 4. >> >> commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") >> commit 8424ecdde7df ("arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges") >> commit 0a30c53573b0 ("arm64: mm: Move reserve_crashkernel() into mem_init()") .. >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index acfae9b41cc8..e7faf5edccfc 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -517,7 +517,7 @@ static void __init map_mem(pgd_t *pgdp) >> */ >> BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end)); >> >> - if (can_set_direct_map() || crash_mem_map || IS_ENABLED(CONFIG_KFENCE)) >> + if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE)) >> flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; >> >> /* >> @@ -528,6 +528,14 @@ static void __init map_mem(pgd_t *pgdp) >> */ >> memblock_mark_nomap(kernel_start, kernel_end - kernel_start); >> >> +#ifdef CONFIG_KEXEC_CORE >> + if (crash_mem_map && !crashk_res.end) >> + flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; > > Using IS_ENABLED(ZONE_DMA/DMA32) instead of '!crashk_res.end' would be more > efficient and a bit more explicit IMO. Sure, I will make change in a follow up submission. > >> /* map all the memory banks */ >> for_each_mem_range(i, &start, &end) { >> if (start >= end) >> @@ -554,6 +562,20 @@ static void __init map_mem(pgd_t *pgdp) >> __map_memblock(pgdp, kernel_start, kernel_end, >> PAGE_KERNEL, NO_CONT_MAPPINGS); >> memblock_clear_nomap(kernel_start, kernel_end - kernel_start); >> +#ifdef CONFIG_KEXEC_CORE >> + /* >> + * Use page-level mappings here so that we can shrink the region >> + * in page granularity and put back unused memory to buddy system >> + * through /sys/kernel/kexec_crash_size interface. >> + */ >> + if (crashk_res.end) { > > Same here. Yes. > >> + __map_memblock(pgdp, crashk_res.start, crashk_res.end + 1, >> + PAGE_KERNEL, >> + NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); >> + memblock_clear_nomap(crashk_res.start, >> + resource_size(&crashk_res)); >> + } >> +#endif > > Now, I carefully reviewed the patch and it seems to be doing the right thing. > But even while knowlegable on the topic, it took a good amount of effort to > untangle the possible code paths. I suspect it's going to be painful to > maintain. I'd suggest at least introducing a comment explaining the situation. I appreciate your review. Yes, it took a good amount of time for me (new here) too and glad for your notice. Let me take a shot at explaining in my next revision. > > If there approach if deemed acceptable, I'll test is on the RPi4. Please, your testing on RPi4 would be valuable. Thanks, Vijay > > Regards, > Nicolas