From patchwork Fri Apr 7 01:15:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baoquan He X-Patchwork-Id: 80598 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1417167vqo; Thu, 6 Apr 2023 18:32:36 -0700 (PDT) X-Google-Smtp-Source: AKy350b0hOOK4vvnMY+N0VsnYl7E6QN1Vgfy8LyesMMzvYg/0hUzT4aIZXSvDZat4lM6E9hYRxFC X-Received: by 2002:a17:906:517:b0:93b:b8f3:225d with SMTP id j23-20020a170906051700b0093bb8f3225dmr652462eja.15.1680831156283; Thu, 06 Apr 2023 18:32:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680831156; cv=none; d=google.com; s=arc-20160816; b=BL5FqPeVEwRwkeXJPdN13JnBA1xDVfa8KoG1iEBuCmwYxiZTvdtHyJz+8sAMVsATR4 NMYGFY85ivFV9hVrAauKmr/qjAqMTkLVumzhEY9MGVcHsczsgqiq3BnbE1aprtAmU1n5 fEy8QY7YJpSCpUI/kICNMEUXgUNCi+ZFE5SVLuByESYb01HvVuxCDjv9cBssoEbKHEBT ieh950CFix8fAqb0VYxW4n5KlXx5CeV2yVXBd3q52ul8+xyzxLJw5xC5hrPboV/iP7Yw +P3o4lLORK71Yd7L3IlVwRD1oWAC7R8SUq3vCN0EV7obdbp+cPJUyg3Q8Qr/o0bGbv+A +cpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Oy29AYYgML7Ch0hXumRCRb+rrtZVQXUDb4HMadFEibw=; b=fE+hZvW1qgeN8h5Q4QqlLmpnPcfK49/4xq+V03LuNVuC5d56Cziszey3ZUgDBF6rRv orbb8boxzLFKdZaLalr8h6D9Za4bsAZExkLZFfbScnmRdvxqUu2Q8twv2wYGcZu1+Z3p hovajIt94NzV86tMRCJPIKSNjlkXDacNszWmJTVbghCu8STjtX2R05VyYTbMX+9Dt1hq CMb3hH7OyVThMm6y3dkyVj8yWuf9uJZzfDs/fyJlYQjpe3pBuJs46GiRYCAhPRfS2wmg LSnzNSVQf7YLw2Oh7WuW1xcAsfdaoLEQIjWINgKgPu8EUgogLK0d1tLx3R0CIwW+svzj dAtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=inDxI9uc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y15-20020a17090668cf00b00931f8f04e64si2144249ejr.840.2023.04.06.18.32.12; Thu, 06 Apr 2023 18:32:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=inDxI9uc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238472AbjDGBQS (ORCPT + 99 others); Thu, 6 Apr 2023 21:16:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232519AbjDGBQO (ORCPT ); Thu, 6 Apr 2023 21:16:14 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 739E049FF for ; Thu, 6 Apr 2023 18:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680830127; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oy29AYYgML7Ch0hXumRCRb+rrtZVQXUDb4HMadFEibw=; b=inDxI9ucZ7cCTgwP80CZybLS00EX/xfqa1DTfiNBByYVYHsRXuUU+lAkl1dAmscsC9Yyu/ i25t/3iDKa40yhSjBO0iSoG5k30X0/YSZP+7MU6osIxy45+BqI9Esdo+zE6W63gMH3y9M7 S/BnVWY+DOt2jNDZ9w9Vz7Yy7hVKC9k= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-624-lIi9gKHuOBqBB7clS_i7ww-1; Thu, 06 Apr 2023 21:15:24 -0400 X-MC-Unique: lIi9gKHuOBqBB7clS_i7ww-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 180203806737; Fri, 7 Apr 2023 01:15:24 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-86.pek2.redhat.com [10.72.12.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id E509718EC6; Fri, 7 Apr 2023 01:15:17 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: catalin.marinas@arm.com, rppt@kernel.org, thunder.leizhen@huawei.com, will@kernel.org, ardb@kernel.org, horms@kernel.org, John.p.donnelly@oracle.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Baoquan He Subject: [PATCH v2 1/3] arm64: kdump : take off the protection on crashkernel memory region Date: Fri, 7 Apr 2023 09:15:05 +0800 Message-Id: <20230407011507.17572-2-bhe@redhat.com> In-Reply-To: <20230407011507.17572-1-bhe@redhat.com> References: <20230407011507.17572-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762479210599301559?= X-GMAIL-MSGID: =?utf-8?q?1762479210599301559?= Problem: ======= On arm64, block and section mapping is supported to build page tables. However, currently it enforces to take base page mapping for the whole linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and crashkernel kernel parameter is set. This will cause longer time of the linear mapping process during bootup and severe performance degradation during running time. Root cause: ========== On arm64, crashkernel reservation relies on knowing the upper limit of low memory zone because it needs to reserve memory in the zone so that devices' DMA addressing in kdump kernel can be satisfied. However, the upper limit of low memory on arm64 is variant. And the upper limit can only be decided late till bootmem_init() is called [1]. And we need to map the crashkernel region with base page granularity when doing linear mapping, because kdump needs to protect the crashkernel region via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't support well on splitting the built block or section mapping due to some cpu reststriction [2]. And unfortunately, the linear mapping is done before bootmem_init(). To resolve the above conflict on arm64, the compromise is enforcing to take base page mapping for the entire linear mapping if crashkernel is set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence performance is sacrificed. Solution: ========= Comparing with the base page mapping for the whole linear region, it's better to take off the protection on crashkernel memory region for the time being because the anticipated stamping on crashkernel memory region could only happen in a chance in one million, while the base page mapping for the whole linear region is mitigating arm64 systems with crashkernel set always. [1] https://lore.kernel.org/all/YrIIJkhKWSuAqkCx@arm.com/T/#u [2] https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulienne@suse.de/T/ Signed-off-by: Baoquan He Acked-by: Catalin Marinas Acked-by: Mike Rapoport (IBM) Reviewed-by: Zhen Lei --- arch/arm64/include/asm/kexec.h | 6 ------ arch/arm64/kernel/machine_kexec.c | 20 -------------------- 2 files changed, 26 deletions(-) diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h index 559bfae26715..9ac9572a3bbe 100644 --- a/arch/arm64/include/asm/kexec.h +++ b/arch/arm64/include/asm/kexec.h @@ -102,12 +102,6 @@ void cpu_soft_restart(unsigned long el2_switch, unsigned long entry, int machine_kexec_post_load(struct kimage *image); #define machine_kexec_post_load machine_kexec_post_load - -void arch_kexec_protect_crashkres(void); -#define arch_kexec_protect_crashkres arch_kexec_protect_crashkres - -void arch_kexec_unprotect_crashkres(void); -#define arch_kexec_unprotect_crashkres arch_kexec_unprotect_crashkres #endif #define ARCH_HAS_KIMAGE_ARCH diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index ce3d40120f72..22da7fc1ff50 100644 --- a/arch/arm64/kernel/machine_kexec.c +++ b/arch/arm64/kernel/machine_kexec.c @@ -268,26 +268,6 @@ void machine_crash_shutdown(struct pt_regs *regs) pr_info("Starting crashdump kernel...\n"); } -void arch_kexec_protect_crashkres(void) -{ - int i; - - for (i = 0; i < kexec_crash_image->nr_segments; i++) - set_memory_valid( - __phys_to_virt(kexec_crash_image->segment[i].mem), - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 0); -} - -void arch_kexec_unprotect_crashkres(void) -{ - int i; - - for (i = 0; i < kexec_crash_image->nr_segments; i++) - set_memory_valid( - __phys_to_virt(kexec_crash_image->segment[i].mem), - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 1); -} - #ifdef CONFIG_HIBERNATION /* * To preserve the crash dump kernel image, the relevant memory segments From patchwork Fri Apr 7 01:15:06 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baoquan He X-Patchwork-Id: 80596 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1413338vqo; Thu, 6 Apr 2023 18:23:24 -0700 (PDT) X-Google-Smtp-Source: AKy350bA/JWQuFNqWHkNRUIroHOaBCzqSP0oQXzzyo3VtjRk5piDYwb0I5ynChW1ylJrueZyDN9C X-Received: by 2002:a17:906:58f:b0:930:21a:c80 with SMTP id 15-20020a170906058f00b00930021a0c80mr622371ejn.47.1680830603930; Thu, 06 Apr 2023 18:23:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680830603; cv=none; d=google.com; s=arc-20160816; b=C5kSkgALhlJ9EC43XLrHdnp0D5p4RJCb5RkQd8zYzmrqvVQOzue7D3N0J6snyb21LH AY6F1jwTpCJ5rtrDRyXgDWrl9/LgP/6LVJ46Y0HZsVYHtOX9+8SbEllgNBeFQLz8ApUm znAmHQpBjW9JxfqJI/qIaW5PzGtA5f+cozRZc0NawNih671NdrFRjyzCr2toGgomPAw3 /eXMpeo/1ZCSJImKQBa9pFmKIdteU7XJzrEfp36Ofwq+hyu3Ckr7FpgLHnnExZNgC1cz i99Oq9aZgf4E8kWiSkkyGKYxOO0pmZbdm8H08bDKKrLtcqIb1rVaCpW97KMXXDWZTtua XuIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=5wyhFBqDO1MjHjj4hsjkNBn2UQkr+0AMWB+0eD0EOGw=; b=XxpadPgRBPhRHr+756pIno2996r7JSjdogW6zGfMmHd9vJXXJz0l5Bj2vE/iIaU6rx 7bLN38kTMe+bKnzltKILtdx7mivNzaC/srtUBdCIK/20ho3vAswvGlQEyOq+ItBfCdLC cfwxMpd0u4rnpPraaPffy4ey6wvtMtsYduA24/XCUmGJAcOXvfciLI+jFCIWbWYZuUjS y8v9KicfviM9yXWyIImWTSfPpxMrMkLr132PY1D8K57QJ3L25fjqQ+KJuR4U1+KokutC RJeC+TZ218GTV3faFjyycpeDxMyGwkBjfBsi8Q7geXQY9gyL+gIPEeNwqrZuHj9UsgJ9 Uupg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PijeifTk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fy8-20020a1709069f0800b0093ea57c3e8dsi2313533ejc.534.2023.04.06.18.22.59; Thu, 06 Apr 2023 18:23:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PijeifTk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230321AbjDGBQb (ORCPT + 99 others); Thu, 6 Apr 2023 21:16:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231509AbjDGBQ3 (ORCPT ); Thu, 6 Apr 2023 21:16:29 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A982C83C0 for ; Thu, 6 Apr 2023 18:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680830142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5wyhFBqDO1MjHjj4hsjkNBn2UQkr+0AMWB+0eD0EOGw=; b=PijeifTktCu6Kl86hBfMQqlacvq90SM0pPepD7Qp5kQUmQbBxZJuRHxjKMTyR0rosGgnhh 8fUdE6hdfU78CvJck/+RXya+mpQnaYt8nIHlhcEfWhNxudRvUxJ0l0s59ryQLOazd2rPwW 8G0eNxSTMEY30d2WSlojrLXr5N54x4M= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-642-TfRYGdxlOGyQDUCWR8k82w-1; Thu, 06 Apr 2023 21:15:31 -0400 X-MC-Unique: TfRYGdxlOGyQDUCWR8k82w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D2CD101A550; Fri, 7 Apr 2023 01:15:30 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-86.pek2.redhat.com [10.72.12.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id DB2E218EC7; Fri, 7 Apr 2023 01:15:24 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: catalin.marinas@arm.com, rppt@kernel.org, thunder.leizhen@huawei.com, will@kernel.org, ardb@kernel.org, horms@kernel.org, John.p.donnelly@oracle.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Baoquan He Subject: [PATCH v2 2/3] arm64: kdump: do not map crashkernel region specifically Date: Fri, 7 Apr 2023 09:15:06 +0800 Message-Id: <20230407011507.17572-3-bhe@redhat.com> In-Reply-To: <20230407011507.17572-1-bhe@redhat.com> References: <20230407011507.17572-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762478631567241146?= X-GMAIL-MSGID: =?utf-8?q?1762478631567241146?= After taking off the protection functions on crashkernel memory region, there's no need to map crashkernel region with page granularity during linear mapping. With this change, the system can make use of block or section mapping on linear region to largely improve perforcemence during system bootup and running. Signed-off-by: Baoquan He Acked-by: Catalin Marinas Acked-by: Mike Rapoport (IBM) Reviewed-by: Zhen Lei --- arch/arm64/mm/mmu.c | 43 ------------------------------------------- 1 file changed, 43 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 6f9d8898a025..7556020a27b7 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -510,21 +510,6 @@ void __init mark_linear_text_alias_ro(void) PAGE_KERNEL_RO); } -static bool crash_mem_map __initdata; - -static int __init enable_crash_mem_map(char *arg) -{ - /* - * Proper parameter parsing is done by reserve_crashkernel(). We only - * need to know if the linear map has to avoid block mappings so that - * the crashkernel reservations can be unmapped later. - */ - crash_mem_map = true; - - return 0; -} -early_param("crashkernel", enable_crash_mem_map); - static void __init map_mem(pgd_t *pgdp) { static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN); @@ -554,16 +539,6 @@ 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) { - if (defer_reserve_crashkernel()) - flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; - else if (crashk_res.end) - memblock_mark_nomap(crashk_res.start, - resource_size(&crashk_res)); - } -#endif - /* map all the memory banks */ for_each_mem_range(i, &start, &end) { if (start >= end) @@ -590,24 +565,6 @@ 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); - - /* - * 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. - */ -#ifdef CONFIG_KEXEC_CORE - if (crash_mem_map && !defer_reserve_crashkernel()) { - if (crashk_res.end) { - __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 } void mark_rodata_ro(void) From patchwork Fri Apr 7 01:15:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baoquan He X-Patchwork-Id: 80603 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1424334vqo; Thu, 6 Apr 2023 18:50:36 -0700 (PDT) X-Google-Smtp-Source: AKy350bg5OXC+UYps7qFqJDp71Q/IzjWoktkzyYoqOQabdNogPoQ8hlYxD/b/HuRI3jXExbh3G+d X-Received: by 2002:a17:906:ae55:b0:920:7a99:dcd4 with SMTP id lf21-20020a170906ae5500b009207a99dcd4mr564738ejb.62.1680832235817; Thu, 06 Apr 2023 18:50:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680832235; cv=none; d=google.com; s=arc-20160816; b=O8OJu5uLr1+PEBwbOc2sAyzUB48D65XB/c+Cf+vciG8vqL9jADPzUXRvXFW0W275jT lX9q+3VZ/jVaH1bpwGC4i4OlRyK/1pQ0f6tTr5i2wkgmKXmGFnHKr6HMMb87xg5EgdEF B30u+ngbu2daOt+09KfWHApbZBaOm/jGKukSg/uHqlicVhJs05zVPWBqE5K7bhh8B9GL 1N62AN3nPycsnuxzrbYJroH28mM1GVDOJpRrax7Dn+Dn/DPFcUU7GVlrK5piloFbWxkb M8ttEp/ku0WPDXXG2RdtwXEvxGldKqxZT8/CTqRyxItoxS5ZkS56oOqeEYsDhQFn2EPf iL9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=yTjaXVllxkU/aHGZ94OX1yUAx1aLhOMTauMuyCLZAvA=; b=MmVtpxD7QDtDe0bz6lzFdVSts27EMF2wP/U8SCKP8LsiEt1m38+A/45YdV3WFidJaV YMnz0NMOuvNeGpUqLeKXejG4fwthK1EBfGh2TKMFCd0FpH4nGsjxgPSLvvzzjjDH3u3f 91svGs93Hgg38eeCLhUiKZSgvNxD8yvUQSNunL7Nv75yRn/fRx/ITAPVYIQnIAkYBRw6 z9rrRNnHyIBv29mDFBkxKfZJbhg+DiTC1QHkS8Bt9NYnP6KArBNO+hNRxnqpPzvHFNBs w5aGBe1Dcrr4N5GkXtYttUzu6sqlIdhUUYvQnpzlsSqsFCdI79Mih0z78MvOqcntlucI Di9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YvdvoYTF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e25-20020a170906c01900b009441add9292si1248562ejz.975.2023.04.06.18.50.12; Thu, 06 Apr 2023 18:50:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YvdvoYTF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238821AbjDGBQd (ORCPT + 99 others); Thu, 6 Apr 2023 21:16:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238212AbjDGBQb (ORCPT ); Thu, 6 Apr 2023 21:16:31 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98F295B9A for ; Thu, 6 Apr 2023 18:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680830140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yTjaXVllxkU/aHGZ94OX1yUAx1aLhOMTauMuyCLZAvA=; b=YvdvoYTFgUBCFyxnoVb/x+3RwbMrL04AX51LJSeiBdVtb9jNbCdv5Db3rB0gqHKl8A4Srh SWgB/grlZI8Emk6icUECsffxSs04rfXZ1DBvwfJq4kovhvFMi9NDaboChFF8F0uNLYxIRL 4eDF1ODL49gfs2KMsSYMmFItjpV6FlY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-441-aB3Vm8o1PqWzLKh0TWuknA-1; Thu, 06 Apr 2023 21:15:37 -0400 X-MC-Unique: aB3Vm8o1PqWzLKh0TWuknA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A994E185A78B; Fri, 7 Apr 2023 01:15:36 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-86.pek2.redhat.com [10.72.12.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4190818EC6; Fri, 7 Apr 2023 01:15:30 +0000 (UTC) From: Baoquan He To: linux-kernel@vger.kernel.org Cc: catalin.marinas@arm.com, rppt@kernel.org, thunder.leizhen@huawei.com, will@kernel.org, ardb@kernel.org, horms@kernel.org, John.p.donnelly@oracle.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Baoquan He Subject: [PATCH v2 3/3] arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones Date: Fri, 7 Apr 2023 09:15:07 +0800 Message-Id: <20230407011507.17572-4-bhe@redhat.com> In-Reply-To: <20230407011507.17572-1-bhe@redhat.com> References: <20230407011507.17572-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762480342616089000?= X-GMAIL-MSGID: =?utf-8?q?1762480342616089000?= In commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for platforms with no DMA memory zones"), reserve_crashkernel() is called much earlier in arm64_memblock_init() to avoid causing base apge mapping on platforms with no DMA meomry zones. With taking off protection on crashkernel memory region, no need to call reserve_crashkernel() specially in advance. The deferred invocation of reserve_crashkernel() in bootmem_init() can cover all cases. So revert the whole commit now. Signed-off-by: Baoquan He Reviewed-by: Zhen Lei --- arch/arm64/include/asm/memory.h | 5 ----- arch/arm64/mm/init.c | 34 +++------------------------------ 2 files changed, 3 insertions(+), 36 deletions(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index 78e5163836a0..efcd68154a3a 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -374,11 +374,6 @@ static inline void *phys_to_virt(phys_addr_t x) }) void dump_mem_limit(void); - -static inline bool defer_reserve_crashkernel(void) -{ - return IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32); -} #endif /* !ASSEMBLY */ /* diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 58a0bb2c17f1..66e70ca47680 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -61,34 +61,8 @@ EXPORT_SYMBOL(memstart_addr); * unless restricted on specific platforms (e.g. 30-bit on Raspberry Pi 4). * In such case, ZONE_DMA32 covers the rest of the 32-bit addressable memory, * otherwise it is empty. - * - * Memory reservation for crash kernel either done early or deferred - * depending on DMA memory zones configs (ZONE_DMA) -- - * - * In absence of ZONE_DMA configs arm64_dma_phys_limit initialized - * here instead of max_zone_phys(). This lets early reservation of - * crash kernel memory which has a dependency on arm64_dma_phys_limit. - * Reserving memory early for crash kernel allows linear creation of block - * mappings (greater than page-granularity) for all the memory bank rangs. - * In this scheme a comparatively quicker boot is observed. - * - * If ZONE_DMA configs are defined, crash kernel memory reservation - * is delayed until DMA zone memory range size initialization performed in - * zone_sizes_init(). The defer is necessary to steer clear of DMA zone - * memory range to avoid overlap allocation. So crash kernel memory boundaries - * are not known when mapping all bank memory ranges, which otherwise means - * not possible to exclude crash kernel range from creating block mappings - * so page-granularity mappings are created for the entire memory range. - * Hence a slightly slower boot is observed. - * - * Note: Page-granularity mappings are necessary for crash kernel memory - * range for shrinking its size via /sys/kernel/kexec_crash_size interface. */ -#if IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32) phys_addr_t __ro_after_init arm64_dma_phys_limit; -#else -phys_addr_t __ro_after_init arm64_dma_phys_limit = PHYS_MASK + 1; -#endif /* Current arm64 boot protocol requires 2MB alignment */ #define CRASH_ALIGN SZ_2M @@ -248,6 +222,8 @@ static void __init zone_sizes_init(void) if (!arm64_dma_phys_limit) arm64_dma_phys_limit = dma32_phys_limit; #endif + if (!arm64_dma_phys_limit) + arm64_dma_phys_limit = PHYS_MASK + 1; max_zone_pfns[ZONE_NORMAL] = max_pfn; free_area_init(max_zone_pfns); @@ -408,9 +384,6 @@ void __init arm64_memblock_init(void) early_init_fdt_scan_reserved_mem(); - if (!defer_reserve_crashkernel()) - reserve_crashkernel(); - high_memory = __va(memblock_end_of_DRAM() - 1) + 1; } @@ -457,8 +430,7 @@ void __init bootmem_init(void) * request_standard_resources() depends on crashkernel's memory being * reserved, so do it here. */ - if (defer_reserve_crashkernel()) - reserve_crashkernel(); + reserve_crashkernel(); memblock_dump_all(); }