[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1727179214.git.kai.huang@intel.com>
Date: Wed, 25 Sep 2024 00:13:52 +1200
From: Kai Huang <kai.huang@...el.com>
To: dave.hansen@...el.com,
bp@...en8.de,
tglx@...utronix.de,
peterz@...radead.org,
mingo@...hat.com,
hpa@...or.com,
kirill.shutemov@...ux.intel.com
Cc: x86@...nel.org,
linux-kernel@...r.kernel.org,
pbonzini@...hat.com,
seanjc@...gle.com,
dan.j.williams@...el.com,
thomas.lendacky@....com,
rick.p.edgecombe@...el.com,
isaku.yamahata@...el.com,
ashish.kalra@....com,
bhe@...hat.com,
nik.borisov@...e.com,
sagis@...gle.com
Subject: [PATCH v7 0/5] TDX host: kexec() support
Currently kexec() support and TDX host are muturally exclusive in the
Kconfig. This series adds the TDX host kexec support so that they can
be both enabled in Kconfig.
With this series, the user can kexec (including crash kdump) to the new
kernel at any time regardless of whether TDX has been enabled in the
first kernel. One limitation is if the first kernel has ever enabled
TDX, for now the second kernel cannot use TDX. This is the future work
in my TODO list.
Hi maintainers,
This series aims to go through the tip tree, but I also CC'ed Sean/Paolo
due to when KVM TDX comes to play a KVM patch [*] is needed to complete
the kexec support for TDX. Also copy Dan for TDX connect.
Thanks for your time!
v6 -> v7:
- Address one comment (add a comment) from David Kaplan, and added his
Tested-by for patch 2.
- Change to use "Link: <permalink>" in patch 1.
v6: https://lore.kernel.org/lkml/cover.1725868065.git.kai.huang@intel.com/T/
v5 -> v6:
- Fixed the issue when rebasing to latest tip/master, conflicting with
commit 93c1800b3799 ("x86/kexec: Fix bug with call depth tracking").
- Use cpu_feature_enabled() instead of boot_cpu_has() -- Boris.
- Improve the coverletter to point out if the first kernel has enabled
TDX the second kernel cannot use TDX anymore, and this will be a
future work (as asked by Sagi in the v5).
v5: https://lore.kernel.org/all/47dbc3b5dd6bd7cc3fa94ffe770e22419daf1d01.camel@intel.com/T/
v4 -> v5:
- Rebase to tip/master.
- Remove the TDX-specific callback due to no need to reset TDX private
memory for crash kexec.
- Add a new patch to make module status immutable in reboot notifier
(split from v1) in order to use module status to tell the presence of
TDX private memory.
- Minor changelog updates, trivial comments improvements.
- Add Tom's Reviewed-by tag.
v4: https://lore.kernel.org/all/cover.1713439632.git.kai.huang@intel.com/
v3 -> v4:
- Updated changelog and comments of patch 1/2 per comments from
Kirill and Tom (see specific patch for details).
v3: https://lore.kernel.org/linux-kernel/cover.1712493366.git.kai.huang@intel.com/
v2 -> v3:
- Change to only do WBINVD for bare-metal, as Kirill/Tom pointed out
WBINVD in TDX guests and SEV-ES/SEV-SNP guests triggers #VE.
v2: https://lore.kernel.org/linux-kernel/cover.1710811610.git.kai.huang@intel.com/
v1 -> v2:
- Do unconditional WBINVD during kexec() -- Boris
- Change to cover crash kexec() -- Rick
- Add a new patch (last one) to add a mechanism to reset all TDX private
pages due to having to cover crash kexec().
- Other code improvements -- Dave
- Rebase to latest tip/master.
v1: https://lore.kernel.org/linux-kernel/cover.1706698706.git.kai.huang@intel.com/
=== More information ===
If the kernel has ever enabled TDX, part of system memory remains TDX
private memory when kexec happens. E.g., the PAMT (Physical Address
Metadata Table) pages used by the TDX module to track each TDX memory
page's state are never freed once the TDX module is initialized. TDX
guests also have guest private memory and secure-EPT pages.
Similar to AMD SME, to support kexec the kernel needs to flush dirty
cachelines for TDX private memory before booting to the second kernel.
Also, the kernel needs to reset TDX private memory to normal (using
MOVDIR64B) before booting to the second kernel when the platform has
"partial write machine check" erratum, otherwise the second kernel may
see unexpected machine check.
The majority code change in this series handles "resetting TDX private
memory" (flushing cache part is relatively straightforward). Due to
currently the kernel doesn't have a unified way to tell whether a given
page is TDX private or not, this series chooses to only reset PAMT in
the core-kernel kexec code, but requires the in-kernel TDX users (e.g.,
KVM to reset the TDX private pages that they manage (see [*]).
This series also covers crash kexec, but no special handling is needed
for crash kexec:
1) kdump kernel uses reserved memory from the first kernel, but the
reserved memory will never be used as TDX memory.
2) /proc/vmcore in the kdump kernel will only be used for read, but read
itself won't poison TDX private memory thus won't cause unexpected
machine check (only "partial write" will).
Note, if the first kernel has ever enabled TDX, after kexec the second
kernel for now cannot use TDX anymore. This is because when the second
kernel tries to initialize TDX module it fails on the first SEAMCALL.
More (non-trivial) work will be needed for the second kernel to use TDX,
e.g., one solution is to just reload the TDX module from the location
where BIOS loads the TDX module (/boot/efi/EFI/TDX/). This series
doesn't cover this, but leave this as future work.
[*]: https://github.com/intel/tdx/commit/f5ef6cf63e34c5364cd88df52f91f05e72cb49b2
Kai Huang (5):
x86/kexec: do unconditional WBINVD for bare-metal in stop_this_cpu()
x86/kexec: do unconditional WBINVD for bare-metal in relocate_kernel()
x86/virt/tdx: Make module initializatiton state immutable in reboot
notifier
x86/kexec: Reset TDX private memory on platforms with TDX erratum
x86/virt/tdx: Remove the !KEXEC_CORE dependency
arch/x86/Kconfig | 1 -
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/include/asm/tdx.h | 2 +
arch/x86/kernel/machine_kexec_64.c | 37 +++++++++----
arch/x86/kernel/process.c | 19 ++++---
arch/x86/kernel/relocate_kernel_64.S | 19 +++++--
arch/x86/virt/vmx/tdx/tdx.c | 78 ++++++++++++++++++++++++++++
7 files changed, 132 insertions(+), 26 deletions(-)
base-commit: a6f489fee2633f8595934a850981bd4284abdbba
--
2.46.0
Powered by blists - more mailing lists