From: Ashish Kalra <Ashish.Kalra@amd.com>
To: <linux-tip-commits@vger.kernel.org>
Cc: <bp@alien8.de>, <thomas.lendacky@amd.com>, <michael.roth@amd.com>,
<x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec.
Date: Mon, 15 Apr 2024 21:09:24 +0000 [thread overview]
Message-ID: <96b2949cf225501d686b47070c7bbad341e160a3.1713212104.git.ashish.kalra@amd.com> (raw)
In-Reply-To: <cover.1713212104.git.ashish.kalra@amd.com>
From: Ashish Kalra <ashish.kalra@amd.com>
Handle cases where the RMP table placement in the BIOS is
not 2M aligned and then the kexec kernel could try to allocate
from within that chunk and that causes a fatal RMP fault.
Check if RMP table start & end physical range in e820_table
is not aligned to 2MB and in that case use e820__range_update()
to map this range to reserved.
The callback to apply these RMP table fixups needs to be called
after the e820 tables are setup/populated and before the e820 map
has been converted to the standard Linux memory resources and e820 map
is no longer used and modifying it has no effect.
Fixes: c3b86e61b756 ("x86/cpufeatures: Enable/unmask SEV-SNP CPU feature")
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
arch/x86/include/asm/sev.h | 2 ++
arch/x86/mm/mem_encrypt.c | 3 +++
arch/x86/virt/svm/sev.c | 44 ++++++++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+)
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 7f57382afee4..6600ac467cf9 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -269,6 +269,7 @@ int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 asid, bool immut
int rmp_make_shared(u64 pfn, enum pg_level level);
void snp_leak_pages(u64 pfn, unsigned int npages);
void kdump_sev_callback(void);
+void snp_rmptable_e820_fixup(void);
#else
static inline bool snp_probe_rmptable_info(void) { return false; }
static inline int snp_lookup_rmpentry(u64 pfn, bool *assigned, int *level) { return -ENODEV; }
@@ -282,6 +283,7 @@ static inline int rmp_make_private(u64 pfn, u64 gpa, enum pg_level level, u32 as
static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV; }
static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
static inline void kdump_sev_callback(void) { }
+static inline void snp_rmptable_e820_fixup(void) {}
#endif
#endif
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 6f3b3e028718..765ce94e4b89 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -102,6 +102,9 @@ void __init mem_encrypt_setup_arch(void)
phys_addr_t total_mem = memblock_phys_mem_size();
unsigned long size;
+ if (cpu_feature_enabled(X86_FEATURE_SEV_SNP))
+ snp_rmptable_e820_fixup();
+
if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
return;
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index ab0e8448bb6e..d999ff7f1671 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -163,6 +163,50 @@ bool snp_probe_rmptable_info(void)
return true;
}
+/*
+ * Callback to do any RMP table fixups, needs to be called
+ * after e820__memory_setup(), after the e820 tables are
+ * setup/populated and before e820__reserve_resources(), before
+ * the e820 map has been converted to the standard Linux memory
+ * resources and e820 map is no longer used and modifying it
+ * has no effect.
+ */
+void __init snp_rmptable_e820_fixup(void)
+{
+ u64 pa;
+
+ /*
+ * Handle cases where the RMP table placement in the BIOS is not 2M aligned
+ * and then the kexec kernel could try to allocate from within that chunk
+ * and that causes a fatal RMP fault. Check if RMP table start & end
+ * physical range in e820_table is not aligned to 2MB and in that case use
+ * e820__range_update() to map this range to reserved, e820__range_update()
+ * nicely handles partial range update and also merges any consecutive
+ * ranges of the same type.
+ */
+ pa = probed_rmp_base;
+ if (!IS_ALIGNED(pa, PMD_SIZE)) {
+ pa = ALIGN_DOWN(pa, PMD_SIZE);
+ if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
+ pr_info("Reserving start of RMP table on a 2MB boundary [0x%016llx]\n", pa);
+ e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ }
+ }
+
+ pa = probed_rmp_base + probed_rmp_size;
+ if (!IS_ALIGNED(pa, PMD_SIZE)) {
+ pa = ALIGN_DOWN(pa, PMD_SIZE);
+ if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
+ pr_info("Reserving end of RMP table on a 2MB boundary [0x%016llx]\n", pa);
+ e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ e820__range_update_kexec(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ e820__range_update_firmware(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+ }
+ }
+}
+
/*
* Do the necessary preparations which are verified by the firmware as
* described in the SNP_INIT_EX firmware command description in the SNP
--
2.34.1
next prev parent reply other threads:[~2024-04-15 21:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 21:08 [PATCH v2 0/2] Apply RMP table fixups for kexec Ashish Kalra
2024-04-15 21:09 ` [PATCH v2 1/2] x86/e820: Expose API to update e820 kexec and firmware tables externally Ashish Kalra
2024-04-20 11:20 ` Borislav Petkov
2024-04-15 21:09 ` Ashish Kalra [this message]
2024-04-20 13:05 ` [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec Borislav Petkov
2024-04-24 23:48 ` Kalra, Ashish
2024-04-26 12:58 ` Borislav Petkov
2024-04-26 14:56 ` Kalra, Ashish
2024-04-20 11:08 ` [PATCH v2 0/2] Apply " Borislav Petkov
2024-04-24 19:10 ` Kalra, Ashish
2024-04-26 12:49 ` Borislav Petkov
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=96b2949cf225501d686b47070c7bbad341e160a3.1713212104.git.ashish.kalra@amd.com \
--to=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=thomas.lendacky@amd.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).