Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5755364ybe; Tue, 10 Sep 2019 08:21:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqxUg7BL6Q1DhhmK8UVtmxeUijz67JGmRMSn6EALfza/RWN1KrujXeNIIkwL4Cd7ApvqhB7z X-Received: by 2002:aa7:da8b:: with SMTP id q11mr31169569eds.19.1568128874726; Tue, 10 Sep 2019 08:21:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568128874; cv=none; d=google.com; s=arc-20160816; b=LBwYOiGXAgZidxMJlLiTY67IfD7OZ5VE07b8ctHgA6pM9+9HA+fQMemSUFjSDSKJq9 V9oJXQE6vPy2Z+zVM/le7UcFymWMS4Ckgt/vd8g/cvO6U9ZWrcgyuCWaTdPEjX69PlC8 4DnVFw6RZp1DdxrIcUZ5LBzNyWIMaJpa5mf5MMA5F5tXH/by91FoNvxxvHt8Hzhvm6+8 Id3DrR2+IZFKJLg/hMVL6DPMeYfVbRyunTPK9b4fvy0CodFi9MwwsgJEZ28XU83tA6ko 7vQCX1+K6XlHzOM4/FoLZ9kzjhVau/gFc6PrvtaYz85/rxIsiRzsyU8QWUqdX2gXiAyQ 9J3g== 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=5Bw4jR7eVZppueYwDtbLeeBk79JdppIFhBzK+EebZbo=; b=fDqFpZCWfwsGXCXhfZtD0B0xJ2xtxzol7WBtvtfM0NNVipIRC+IbnVV2VwnoRQXWMT pMa+IC0s+wHk1sIdIqJCjJP95DqxDl0vIFtJRHudsyT1I2RwKO4El8wPcw/AakndFNl1 vhhyzZtlkGaSfr8bryr1xE/MNZ/QqabidEC8XOElxMVuEXssCf4essasykkiAiSdJaSr r0yaAN15rITj1ipxkBajsCDgDyiBvAzNhMfDlkyRzU721Rq/q2ukq+3qX6Ux/xwlDqMQ uuSLBPgPqEJ/ivw6vtjpwDtRCXHdQzDRgOOhjk3cy28kZGdRVpGiOtrF1Z6JymrD3DCK 8voQ== 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 d25si10289944eds.61.2019.09.10.08.20.50; Tue, 10 Sep 2019 08:21:14 -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 S2393909AbfIJPSs (ORCPT + 99 others); Tue, 10 Sep 2019 11:18:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43158 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726060AbfIJPSs (ORCPT ); Tue, 10 Sep 2019 11:18:48 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4E9C300BCE9; Tue, 10 Sep 2019 15:18:47 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-75.pek2.redhat.com [10.72.12.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id B6BEC19C58; Tue, 10 Sep 2019 15:18:40 +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 v3 0/2] x86/kdump: Reserve extra memory when SME or SEV is active Date: Tue, 10 Sep 2019 23:13:39 +0800 Message-Id: <20190910151341.14986-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Tue, 10 Sep 2019 15:18:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series let kernel reserve extra memory for kdump when SME or SEV is active. When SME or SEV is active, SWIOTLB will be always 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. With high reservation an extra low memory region will always be reserved and that is enough for SWIOTLB. With offset format, user should be fully aware of any possible kdump kernel memory requirement and have to organize the memory usage carefully. Patch 1/2 simply split some code out of the reserve_crashkernel, prepare for the change of next patch. Patch 2/2 will let crashkernel reserve extra memory when SME or SEV is active, and explains more details and history about why this change is introduced. Update from V2: - Refactor and split some function out of reserve_crashkernel to make it cleaner, as suggested by Borislav Petkov - Split into 2 patches 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 Kairui Song (2): x86/kdump: Split some code out of reserve_crashkernel x86/kdump: Reserve extra memory when SME or SEV is active arch/x86/kernel/setup.c | 106 ++++++++++++++++++++++++++++------------ 1 file changed, 74 insertions(+), 32 deletions(-) -- 2.21.0