From: Kairui Song <kasong@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
x86@kernel.org, Kairui Song <kasong@redhat.com>
Subject: [PATCH] x86/kdump: Print a notice if SME/SEV is active on crash reservation
Date: Fri, 25 Oct 2019 01:14:17 +0800 [thread overview]
Message-ID: <20191024171417.14175-1-kasong@redhat.com> (raw)
SME/SEV requires SWIOTLB to be force enabled in both first kernel
and kdump kernel, the detail is covered in following 3 commits:
- commit c7753208a94c ("x86, swiotlb: Add memory encryption support")
force enables SWIOTLB when SME is active, even if there is less than
4G of memory, to support DMA of devices that not support address with
the encrypt bit.
- commit aba2d9a6385a ("iommu/amd: Do not disable SWIOTLB if SME is active")
kernel keep SWIOTLB enabled even if there is an IOMMU, to support special
devices that IOMMU can't handle.
- commit d7b417fa08d1 ("x86/mm: Add DMA support for SEV memory encryption")
force enables SWIOTLB when SEV is active unconditionally.
Force enabling SWIOTLB in kdump kernel will make it easily run out of
already scarce pre-reserved crashkernel memory.
The crashkernel value is user specified, and kernel should respect the
given value to make the behavior clear and controllable. And currently
there is no way kernel could estimate the crashkernel value after all.
So when SME/SEV is active, just print a notice to let the user know the
situation and adjust the crashkernel value accordingly. Suppress the
notice if high reservation is used, as high reservation will always
reserve a dedicated low memory region which will cover the SWIOTLB.
Signed-off-by: Kairui Song <kasong@redhat.com>
---
arch/x86/kernel/setup.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 77ea96b794bd..d5ceea03c0a3 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -594,6 +594,13 @@ static void __init reserve_crashkernel(void)
return;
}
+ if (crash_base < (1ULL << 32) && mem_encrypt_active()) {
+ pr_notice("Memory encrytion is active, SWIOTLB is required to work,\n"
+ "%luMB of low crash memory will be consumed by it.\n"
+ "Please ensure crashkernel value is large enough.\n",
+ (ALIGN(swiotlb_size_or_default(), SZ_1M) >> 20));
+ }
+
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System RAM: %ldMB)\n",
(unsigned long)(crash_size >> 20),
(unsigned long)(crash_base >> 20),
--
2.21.0
reply other threads:[~2019-10-24 17:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191024171417.14175-1-kasong@redhat.com \
--to=kasong@redhat.com \
--cc=Thomas.Lendacky@amd.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).