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