Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3676401ybl; Sun, 25 Aug 2019 21:47:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGLbUbTvejoD6Av8T/c/N/AbuTNVTvYi9kgDwmECAsAOa7NwT8+wXe+p6Ak7/oR6pzJQNw X-Received: by 2002:a65:50c8:: with SMTP id s8mr14602673pgp.339.1566794859054; Sun, 25 Aug 2019 21:47:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566794859; cv=none; d=google.com; s=arc-20160816; b=0Ft3tpKd06DPGAvSR9QDsV55TvWwGkZ+fEBc1AjUF1fIF4cKxoKlEJ3kqdXRgbMf0I rMgrujU3QTCgRpGsv7bcxoj4uu38DP09wXbsY0r5qkhVJOReAWPsOrhXdLJ4oTPPDeLd 959CahanWykKO+fK7Fh+3Zegs8JdQVLZ1vHn1PY4LN5hysCH2RkiqnDxoMVUjDBunf6t Z4p0WF3/B16UncqoUfZkuGuLoLVKo5SbHrKqNMvonYfyeU4kHBimWCDjebUmDyK+VBDC dOyl+aMUbH0t7ltN6IlXq0juoqiOWvt2MtEnBEBIBeEkwxE6WFNWR5Mk8O2WPtHwjVzE tmzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ZukPwDBcz6BzfXdcER6Q01tjADVnltX8F9L5ViQAVno=; b=RQk49SIgC9gVuDH8M0rk2xhPdK+5VcpjkZR1KJu44Hrm72qqQV+uAl5n3TZXmGrE3Z 1/hCIfYfd9alkhDhbe52DQgWOS9UiPmRPuL41beCjGJvC3ierkky5729CAR/X7S6zaI+ UpzJXq8jsswibzNq3CbGvM0ELtnVV+TBQxWE5a6udcVREkT7c4oIGQYARMqFXFDi5C/O u1ygqiwT1NBVJ7YvlaJM1tOen50jEeBahtgxFVFTlzeWFuVPG3YpjNmyO1ZHIBi+qggf FSzfxuzJrshFoDNxpa7wbUBdJuZvWEEE+BYYaqXssXYZi3ACCKoQUodQFaGbZkPTYfK2 K89Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j21si3899914pfe.32.2019.08.25.21.47.24; Sun, 25 Aug 2019 21:47:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728032AbfHZEqA (ORCPT + 99 others); Mon, 26 Aug 2019 00:46:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45968 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725270AbfHZEqA (ORCPT ); Mon, 26 Aug 2019 00:46:00 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F50C8980E7; Mon, 26 Aug 2019 04:45:59 +0000 (UTC) Received: from wlc-trust-99.pek2.redhat.com (wlc-trust-99.pek2.redhat.com [10.72.3.99]) by smtp.corp.redhat.com (Postfix) with ESMTP id F18366092D; Mon, 26 Aug 2019 04:45:52 +0000 (UTC) From: Kairui Song To: linux-kernel@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Thomas Lendacky , Baoquan He , Lianbo Jiang , Dave Young , x86@kernel.org, "kexec@lists.infradead.org" , Kairui Song Subject: [PATCH v2] x86/kdump: Reserve extra memory when SME or SEV is active Date: Mon, 26 Aug 2019 12:45:35 +0800 Message-Id: <20190826044535.9646-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.67]); Mon, 26 Aug 2019 04:45:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since commit c7753208a94c ("x86, swiotlb: Add memory encryption support"), SWIOTLB will be enabled even if there is less than 4G of memory when SME is active, to support DMA of devices that not support address with the encrypt bit. And commit aba2d9a6385a ("iommu/amd: Do not disable SWIOTLB if SME is active") make the kernel keep SWIOTLB enabled even if there is an IOMMU. Then commit d7b417fa08d1 ("x86/mm: Add DMA support for SEV memory encryption") will always force SWIOTLB to be enabled when SEV is active in all cases. Now, when either SME or SEV is active, SWIOTLB will be force enabled, and this is also true for kdump kernel. As a result kdump kernel will run out of already scarce pre-reserved memory easily. So when SME/SEV is active, reserve extra memory for SWIOTLB to ensure kdump kernel have enough memory, except when "crashkernel=size[KMG],high" is specified or any offset is used. As for the high reservation case, an extra low memory region will always be reserved and that is enough for SWIOTLB. Else if the offset format is used, user should be fully aware of any possible kdump kernel memory requirement and have to organize the memory usage carefully. Signed-off-by: Kairui Song --- Update from V1: - Use mem_encrypt_active() instead of "sme_active() || sev_active()" - Don't reserve extra memory when ",high" or "@offset" is used, and don't print redundant message. - Fix coding style problem arch/x86/kernel/setup.c | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index bbe35bf879f5..221beb10c55d 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -528,7 +528,7 @@ static int __init reserve_crashkernel_low(void) static void __init reserve_crashkernel(void) { - unsigned long long crash_size, crash_base, total_mem; + unsigned long long crash_size, crash_base, total_mem, mem_enc_req; bool high = false; int ret; @@ -550,6 +550,15 @@ static void __init reserve_crashkernel(void) return; } + /* + * When SME/SEV is active, it will always required an extra SWIOTLB + * region. + */ + if (mem_encrypt_active()) + mem_enc_req = ALIGN(swiotlb_size_or_default(), SZ_1M); + else + mem_enc_req = 0; + /* 0 means: find the address automatically */ if (!crash_base) { /* @@ -563,11 +572,19 @@ static void __init reserve_crashkernel(void) if (!high) crash_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_LOW_MAX, - crash_size, CRASH_ALIGN); - if (!crash_base) + crash_size + mem_enc_req, + CRASH_ALIGN); + /* + * For high reservation, an extra low memory for SWIOTLB will + * always be reserved later, so no need to reserve extra + * memory for memory encryption case here. + */ + if (!crash_base) { + mem_enc_req = 0; crash_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_HIGH_MAX, crash_size, CRASH_ALIGN); + } if (!crash_base) { pr_info("crashkernel reservation failed - No suitable area found.\n"); return; @@ -575,6 +592,7 @@ static void __init reserve_crashkernel(void) } else { unsigned long long start; + mem_enc_req = 0; start = memblock_find_in_range(crash_base, crash_base + crash_size, crash_size, 1 << 20); @@ -583,6 +601,13 @@ static void __init reserve_crashkernel(void) return; } } + + if (mem_enc_req) { + pr_info("Memory encryption is active, crashkernel needs %ldMB extra memory\n", + (unsigned long)(mem_enc_req >> 20)); + crash_size += mem_enc_req; + } + ret = memblock_reserve(crash_base, crash_size); if (ret) { pr_err("%s: Error reserving crashkernel memblock.\n", __func__); -- 2.21.0