From nobody Fri Apr 3 17:37:49 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E255B273D6D; Thu, 2 Apr 2026 06:32:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111540; cv=none; b=sbPRI/85f02uA/dhrzbcpwZg5/7uRmTujKrlC3sLi3cQpTWEcgORgwoWCS+AqgupugkML+Mec0QjRIBCOfAIcLISHP/KXEoLRWpzLFXUC6XqhJLmeUXy9/G8omjMeFZ4/E8Qfiam/FuvqI/VYZi85mitxHkkfSlFfWNpJr15vAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111540; c=relaxed/simple; bh=Y7Ua1tTxbyu3RHHfvSbNLGU41KLjM+Y+DPVJVkjgAKU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Pkl745zK491vGuxTlDSm5y/oE4ka/tlEvlCZ9NTU0nNaisSg+x1qAkfJjYJ4EN1Sv89OkteYiJAUrAjV35SiWJ5988fUjmmVrh8FWSJD3aRPC/NXMIYod+8Tzer/rZ2bPGGrkJhHXakm0Bx32tjyWJZzTtq75kOcS05LZAYuVEc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=na9thpgf; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="na9thpgf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775111539; x=1806647539; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=Y7Ua1tTxbyu3RHHfvSbNLGU41KLjM+Y+DPVJVkjgAKU=; b=na9thpgfs5gNd964KVcvZfjAnQW5MDz+CBBVvsIelQ5HAb8OGbzW0p3K AYqasecmgteQ/22IaF/9Bm3/yIHAiq0KicCL93/uHlRMXrChJxkU1CCk4 Dt3Zi3cJK2nEbI9sPp/cZVLidxQS7zgxXP+ndcPoC49GEMWahhgRlRZxm S5SeqrDubiv6BGFcGKPpJOS/HPTBgpuWF1WdMfFyUY6ks3x4TENTahB2d k1ISVcAQrx7uuA/K8QpHaq2is3/73/NglllXwZ8uQ2zl6rRXyzkl6KGG1 Yp5cBxNWpwkELNgJjQ7rtGWQ5BNqSOM+5gV92MFpt8+n+ita/COGQ39Dy g==; X-CSE-ConnectionGUID: f2ZkYrKZQqq8+b33YyBGuw== X-CSE-MsgGUID: dufkjK/WR0eOyDP3oTRVaw== X-IronPort-AV: E=McAfee;i="6800,10657,11746"; a="75884370" X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="75884370" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:18 -0700 X-CSE-ConnectionGUID: ZkgXaa7nQuGfvTrmMZCHYQ== X-CSE-MsgGUID: J3i6E2J0RI+jehS8/ngL1g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="222042377" Received: from vverma7-desk1.amr.corp.intel.com (HELO [192.168.1.200]) ([10.124.223.130]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:17 -0700 From: Vishal Verma Date: Thu, 02 Apr 2026 00:32:01 -0600 Subject: [PATCH v3 1/5] x86/tdx: Move TDX architectural error codes into Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260402-fuller_tdx_kexec_support-v3-1-34438d7094bf@intel.com> References: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> In-Reply-To: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , Paolo Bonzini Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Vishal Verma , Chao Gao , Kiryl Shutsemau , Kiryl Shutsemau X-Mailer: b4 0.16-dev-ad80c X-Developer-Signature: v=1; a=openpgp-sha256; l=2852; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=agfGwcrJeqkoZjgG7fo/o/bPRZsU/u//ymwQrBtXti4=; b=owGbwMvMwCXGf25diOft7jLG02pJDJnneAuEPP3evk44muz+/Zce24r+Xd16ivJPI21aJvNU8 qaKRgh2lLIwiHExyIopsvzd85HxmNz2fJ7ABEeYOaxMIEMYuDgFYCJTFBgZTpwxuC/6uzjEgvEB +6aKgrmxu/ZPmCY79SWzwg6pXZNefmD47zntf8Btrd6jG861PxZI9lZbefF/x9RTp7v3iN6ee+l VFDsA X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF From: "Kirill A. Shutemov" Today there are two separate locations where TDX error codes are defined: arch/x86/include/asm/tdx.h arch/x86/kvm/vmx/tdx_errno.h They have some overlap that is already defined similarly. Reduce the duplication by unifying the architectural error codes at: asm/shared/tdx_errno.h ...and update the headers that contained the duplicated definitions to include the new unified header. "asm/shared" is used for sharing TDX code between the early compressed code and the normal kernel code. While the compressed code for the guest doesn't use these error code header definitions today, it does make the types of calls that return the values they define. So place the defines in "shared" location so that it can, but leave such cleanups for future changes. [Rick: enhance log] [Vishal: reduce to a simple move of architectural defines only] Signed-off-by: Kirill A. Shutemov Signed-off-by: Rick Edgecombe Signed-off-by: Vishal Verma Reviewed-by: Chao Gao Acked-by: Sean Christopherson --- arch/x86/include/asm/shared/tdx.h | 1 + arch/x86/{kvm/vmx =3D> include/asm/shared}/tdx_errno.h | 7 +++---- arch/x86/kvm/vmx/tdx.h | 1 - 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/share= d/tdx.h index 8bc074c8d7c6..6a1646fc2b2f 100644 --- a/arch/x86/include/asm/shared/tdx.h +++ b/arch/x86/include/asm/shared/tdx.h @@ -4,6 +4,7 @@ =20 #include #include +#include =20 #define TDX_HYPERCALL_STANDARD 0 =20 diff --git a/arch/x86/kvm/vmx/tdx_errno.h b/arch/x86/include/asm/shared/tdx= _errno.h similarity index 92% rename from arch/x86/kvm/vmx/tdx_errno.h rename to arch/x86/include/asm/shared/tdx_errno.h index 6ff4672c4181..3c1e8ce716e3 100644 --- a/arch/x86/kvm/vmx/tdx_errno.h +++ b/arch/x86/include/asm/shared/tdx_errno.h @@ -1,8 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* architectural status code for SEAMCALL */ - -#ifndef __KVM_X86_TDX_ERRNO_H -#define __KVM_X86_TDX_ERRNO_H +#ifndef _ASM_X86_SHARED_TDX_ERRNO_H +#define _ASM_X86_SHARED_TDX_ERRNO_H =20 #define TDX_SEAMCALL_STATUS_MASK 0xFFFFFFFF00000000ULL =20 @@ -37,4 +36,4 @@ #define TDX_OPERAND_ID_SEPT 0x92 #define TDX_OPERAND_ID_TD_EPOCH 0xa9 =20 -#endif /* __KVM_X86_TDX_ERRNO_H */ +#endif /* _ASM_X86_SHARED_TDX_ERRNO_H */ diff --git a/arch/x86/kvm/vmx/tdx.h b/arch/x86/kvm/vmx/tdx.h index b5cd2ffb303e..ac8323a68b16 100644 --- a/arch/x86/kvm/vmx/tdx.h +++ b/arch/x86/kvm/vmx/tdx.h @@ -3,7 +3,6 @@ #define __KVM_X86_VMX_TDX_H =20 #include "tdx_arch.h" -#include "tdx_errno.h" =20 #ifdef CONFIG_KVM_INTEL_TDX #include "common.h" --=20 2.53.0 From nobody Fri Apr 3 17:37:49 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D069E31AF1B; Thu, 2 Apr 2026 06:32:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; cv=none; b=Bx87vuPs6Kj+9B9/MvviGYsPNChbrHHMNXnwpO61KN3uI8LTxKYczIDH5pe7VP+fsX8nsdN+f7w16JFlaC5fKouNTGAGkLYcvWRVM4C2LZhjWNZZhXVXyaBm+2/J7p4OLegnFsxC8TCkH0UgLWENRglLDr//ydpeS0Vrkj/F8jo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; c=relaxed/simple; bh=fr2AGC4DAtRDRQoO7qlnwxMNcELWQ3TmgBcgjqT5wAQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=TKfXwHmmnqym6JGNmDQCVEAqA9blGzQEEJA18WoszEz7XxTiML6zDB0MhpemlWE08PYoZhBgOCm5Ye4rE/WU7cqMTESXYph00IN+pU5dGOtraBJUCbg2z9Y+efbJPjB539cnxv/P4kaSj9+CgWTnY7i4Hp3/nh18pm/6g3cbF5g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=L4nHLy5A; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="L4nHLy5A" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775111540; x=1806647540; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=fr2AGC4DAtRDRQoO7qlnwxMNcELWQ3TmgBcgjqT5wAQ=; b=L4nHLy5AcIJUxTee2OEbCNH4HLD6xeQDe+rpX1lQv5lvnG/Al2FoYjki U4G12xif2v+4qp+syG04coCS6NxXLrnvSnL32p1hiGKq8agCB1CL25kaj qAhilgsygahFJOUkP1XwHOc19dNXK76KjzQBiVcTQiRMk98wXJR/DeLt6 vlk2VSEHRSb7A7iiFr9P/veJGiSoA0L0GwoiyrNxDpsYCQncMhM68jp4d IjIoNS4jJ2A8tYSjvVgvkWhLFnL44wwJf2ac+prwHroQ1s3j96JPs2zdI Edztt38OMcmRi9Gb1H4DllVod8oNUkJe5EDCkDFWoHotTwWrlv376R9oD Q==; X-CSE-ConnectionGUID: C6F4xyMGRQefJMR/AV/EWQ== X-CSE-MsgGUID: rtB8QDufS8Snc8z+EndXLA== X-IronPort-AV: E=McAfee;i="6800,10657,11746"; a="75884377" X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="75884377" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:19 -0700 X-CSE-ConnectionGUID: to4XrwE1SS27pFHYDmCpMg== X-CSE-MsgGUID: H7ysO7guRKu096s7W4HKkA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="222042380" Received: from vverma7-desk1.amr.corp.intel.com (HELO [192.168.1.200]) ([10.124.223.130]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:17 -0700 From: Vishal Verma Date: Thu, 02 Apr 2026 00:32:02 -0600 Subject: [PATCH v3 2/5] x86/virt/tdx: Pull kexec cache flush logic into arch/x86 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260402-fuller_tdx_kexec_support-v3-2-34438d7094bf@intel.com> References: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> In-Reply-To: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , Paolo Bonzini Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Vishal Verma , Chao Gao , Kai Huang X-Mailer: b4 0.16-dev-ad80c X-Developer-Signature: v=1; a=openpgp-sha256; l=5737; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=tQJ89P+w7vtSKyTW13SidV3e91okmzzHzGpQV5uA2V0=; b=owGbwMvMwCXGf25diOft7jLG02pJDJnneAv+Vhg8f3bxio3Ln7sJz5OeOlzYutfiGM80s+Wuy 3//8ufp6yhlYRDjYpAVU2T5u+cj4zG57fk8gQmOMHNYmUCGMHBxCsBEZvIx/GZ1fF6xbxPbdpZX lbrWCqmrEg/ceP0zt+/M3Gh13g1Rp7sYGU4oqHq/CWoL/BjtuevWI76lq5ruHv45YcuTnQ93RW3 fWMEMAA== X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF From: Rick Edgecombe KVM tries to take care of some required cache flushing earlier in the kexec path in order to be kind to some long standing races that can occur later in the operation. Until recently, VMXOFF was handled within KVM. Since VMX being enabled is required to make a SEAMCALL, it had the best per-cpu scoped operation to plug the flushing into. So it is kicked off from there. This early kexec cache flushing in KVM happens via a syscore shutdown callback. Now that VMX enablement control has moved to arch/x86, which has grown its own syscore shutdown callback, it no longer make sense for it to live in KVM. It fits better with the TDX enablement managing code. In addition, future changes will add a SEAMCALL that happens immediately before VMXOFF, which means the cache flush in KVM will be too late to flush the cache before the last SEAMCALL. So move it to the newly added TDX arch/x86 syscore shutdown handler. Since tdx_cpu_flush_cache_for_kexec() is no longer needed by KVM, make it static and remove the export. Since it is also not part of an operation spread across disparate components, remove the redundant comments and verbose naming. In the existing KVM based code, CPU offline also funnels through tdx_cpu_flush_cache_for_kexec(). Add an explicit WBINVD in tdx_offline_cpu() as well, even though it may be redundant with WBINVD done elsewhere during CPU offline (e.g. hlt_play_dead()). This avoids relying on fragile code ordering for cache coherency safety. [Vishal: add explicit WBINVD in tdx_offline_cpu()] Signed-off-by: Rick Edgecombe Signed-off-by: Vishal Verma Reviewed-by: Chao Gao Acked-by: Kai Huang Acked-by: Kiryl Shutsemau (Meta) Acked-by: Sean Christopherson --- arch/x86/include/asm/tdx.h | 6 ------ arch/x86/kvm/vmx/tdx.c | 10 ---------- arch/x86/virt/vmx/tdx/tdx.c | 46 ++++++++++++++++++++++++++---------------= ---- 3 files changed, 27 insertions(+), 35 deletions(-) diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index a149740b24e8..bf83a974a0d5 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -226,11 +226,5 @@ static inline const char *tdx_dump_mce_info(struct mce= *m) { return NULL; } static inline const struct tdx_sys_info *tdx_get_sysinfo(void) { return NU= LL; } #endif /* CONFIG_INTEL_TDX_HOST */ =20 -#ifdef CONFIG_KEXEC_CORE -void tdx_cpu_flush_cache_for_kexec(void); -#else -static inline void tdx_cpu_flush_cache_for_kexec(void) { } -#endif - #endif /* !__ASSEMBLER__ */ #endif /* _ASM_X86_TDX_H */ diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index b7264b533feb..50a5cfdbd33e 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -440,16 +440,6 @@ void tdx_disable_virtualization_cpu(void) tdx_flush_vp(&arg); } local_irq_restore(flags); - - /* - * Flush cache now if kexec is possible: this is necessary to avoid - * having dirty private memory cachelines when the new kernel boots, - * but WBINVD is a relatively expensive operation and doing it during - * kexec can exacerbate races in native_stop_other_cpus(). Do it - * now, since this is a safe moment and there is going to be no more - * TDX activity on this CPU from this point on. - */ - tdx_cpu_flush_cache_for_kexec(); } =20 #define TDX_SEAMCALL_RETRIES 10000 diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index cb9b3210ab71..1b2d854ba664 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -184,6 +184,17 @@ static int tdx_online_cpu(unsigned int cpu) return ret; } =20 +static void tdx_cpu_flush_cache(void) +{ + lockdep_assert_preemption_disabled(); + + if (!this_cpu_read(cache_state_incoherent)) + return; + + wbinvd(); + this_cpu_write(cache_state_incoherent, false); +} + static int tdx_offline_cpu(unsigned int cpu) { int i; @@ -220,12 +231,28 @@ static int tdx_offline_cpu(unsigned int cpu) return -EBUSY; =20 done: + /* + * Flush cache on the CPU going offline to ensure no dirty + * cachelines of TDX private memory remain. This may be + * redundant with WBINVD done elsewhere during CPU offline + * (e.g. hlt_play_dead()), but do it explicitly for safety. + */ + tdx_cpu_flush_cache(); x86_virt_put_ref(X86_FEATURE_VMX); return 0; } =20 static void tdx_shutdown_cpu(void *ign) { + /* + * Flush cache in preparation for kexec - this is necessary to avoid + * having dirty private memory cachelines when the new kernel boots, + * but WBINVD is a relatively expensive operation and doing it during + * kexec can exacerbate races in native_stop_other_cpus(). Do it + * now, since this is a safe moment and there is going to be no more + * TDX activity on this CPU from this point on. + */ + tdx_cpu_flush_cache(); x86_virt_put_ref(X86_FEATURE_VMX); } =20 @@ -1920,22 +1947,3 @@ u64 tdh_phymem_page_wbinvd_hkid(u64 hkid, struct pag= e *page) return seamcall(TDH_PHYMEM_PAGE_WBINVD, &args); } EXPORT_SYMBOL_FOR_KVM(tdh_phymem_page_wbinvd_hkid); - -#ifdef CONFIG_KEXEC_CORE -void tdx_cpu_flush_cache_for_kexec(void) -{ - lockdep_assert_preemption_disabled(); - - if (!this_cpu_read(cache_state_incoherent)) - return; - - /* - * Private memory cachelines need to be clean at the time of - * kexec. Write them back now, as the caller promises that - * there should be no more SEAMCALLs on this CPU. - */ - wbinvd(); - this_cpu_write(cache_state_incoherent, false); -} -EXPORT_SYMBOL_FOR_KVM(tdx_cpu_flush_cache_for_kexec); -#endif --=20 2.53.0 From nobody Fri Apr 3 17:37:49 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00C4631B131; Thu, 2 Apr 2026 06:32:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; cv=none; b=B1jyzJqXhFk1dQ2FH3gILUcVMxbZqPsCJi7KGRKhzXdar7z7zQD5n2nYmM0NXZCECQFyJL8XArAAjebU/oY6U45LzCb5g/Umy0AYLdimHA2NcOO37a/Rgqqsada1PI6IZZrEBHtQnho0sm8I50k+nQUEDmRblsn6vo8Ivi+Ht8c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; c=relaxed/simple; bh=L0GDKUyMS3vDRDQ4Bwa6uOWIZAf2jVJIXpcNzmI0SKA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=V4sxv8j0LkgveCE1CtkzP2/AHT+ZCUhW8Kt0ho4Z8TcxvNUUqIqfO4MM4iZdHv6ZDo1/SdiCx6nzQpVM/o+PdI6aCzuGPjXlc0KJWzhm+j3InYXAak8amMkmnqe6kwbV6o665SAsMCOpU2zAqR1z9Y32zlrtQf0DqtfkROxR09s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZWlHAiqG; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZWlHAiqG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775111540; x=1806647540; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=L0GDKUyMS3vDRDQ4Bwa6uOWIZAf2jVJIXpcNzmI0SKA=; b=ZWlHAiqGOlK9wG8L2pXg6dhKqYduJ0/Z2K1niRbWopp9t8fP7nzQCByn kLEXPG0ovH1uPu9oL1fD821GE3nbhuGV4PoOm4eScH1ksyd9ndfz2Nl69 Eicwpdzl8zjysxlx3uDVAU/JmX9NFx4T0czyxvkk59gu9l8WbceB8GC0d IKKWrpAdpwsp8aUARdAAt1XWo5JHWOWgDWCY3jvTC3VxLdDjjzBUtuqf/ MbHkbrRjCES9MafqyZEj+MmwdvVB8NZ85YvcY7oxPwwIRUKmK8QsJF/SL 6JQflix675jw2q8WPuxEbPYqbZH+7FLpXIpZWF7+T5WNJYA/rlsYELPtL Q==; X-CSE-ConnectionGUID: h5Ct9InGSFCH2FpYonyuag== X-CSE-MsgGUID: wKrmN+QQT4OIx2Y9o/w2gg== X-IronPort-AV: E=McAfee;i="6800,10657,11746"; a="75884384" X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="75884384" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:19 -0700 X-CSE-ConnectionGUID: OahonsBMSOCsH73omgS2Kw== X-CSE-MsgGUID: eW9MGh/6RlSdLmFyC/FeyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="222042383" Received: from vverma7-desk1.amr.corp.intel.com (HELO [192.168.1.200]) ([10.124.223.130]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:18 -0700 From: Vishal Verma Date: Thu, 02 Apr 2026 00:32:03 -0600 Subject: [PATCH v3 3/5] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260402-fuller_tdx_kexec_support-v3-3-34438d7094bf@intel.com> References: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> In-Reply-To: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , Paolo Bonzini Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Vishal Verma , Chao Gao , Kai Huang X-Mailer: b4 0.16-dev-ad80c X-Developer-Signature: v=1; a=openpgp-sha256; l=6333; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=L0GDKUyMS3vDRDQ4Bwa6uOWIZAf2jVJIXpcNzmI0SKA=; b=owGbwMvMwCXGf25diOft7jLG02pJDJnneAtey7nkh6dtEDtlaGTaMsmwXvCB2Em/08dP2Te5n pFVzFbpKGVhEONikBVTZPm75yPjMbnt+TyBCY4wc1iZQIYwcHEKwER+lDMy3J3Q16E/O/e3ebmX wXfhigflb3N/i8y91LK72SHilwZbJ8N/v8f2/+b7Z6y5x/Gv7Y/vtx2LeBtOy+ZGaa27uHpue5s +GwA= X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF Some early TDX-capable platforms have an erratum where a partial write to TDX private memory can cause a machine check on a subsequent read. On these platforms, kexec and kdump have been disabled in these cases, because the old kernel cannot safely hand off TDX state to the new kernel. Later TDX modules support the TDH.SYS.DISABLE SEAMCALL, which provides a way to cleanly disable TDX and allow kexec to proceed. The new SEAMCALL has an enumeration bit, but that is ignored. It is expected that users will be using the latest TDX module, and the failure mode for running the missing SEAMCALL on an older module is not fatal. This can be a long running operation, and the time needed largely depends on the amount of memory that has been allocated to TDs. If all TDs have been destroyed prior to the sys_disable call, then it is fast, with only needing to override the TDX module memory. After the SEAMCALL completes, the TDX module is disabled and all memory resources allocated to TDX are freed and reset. The next kernel can then re-initialize the TDX module from scratch via the normal TDX bring-up sequence. The SEAMCALL can return two different error codes that expect a retry. - TDX_INTERRUPTED_RESUMABLE can be returned in the case of a host interrupt. However, it will not return until it makes some forward progress, so we can expect to complete even in the case of interrupt storms. - TDX_SYS_BUSY will be returned on contention with other TDH.SYS.* SEAMCALLs, however a side effect of TDH.SYS.DISABLE is that it will block other SEAMCALLs once it gets going. So this contention will be short lived. So loop infinitely on either of these error codes, until success or other error. An error is printed if the SEAMCALL fails with anything other than the error codes that cause retries, or 'synthesized' error codes produced for #GP or #UD. e.g., an old module that has been properly initialized, that doesn't implement SYS_DISABLE, returns TDX_OPERAND_INVALID. This prints: virt/tdx: TDH.SYS.DISABLE failed: 0xc000010000000000 But a system that doesn't have any TDX support at all doesn't print anything. Co-developed-by: Rick Edgecombe Signed-off-by: Rick Edgecombe Signed-off-by: Vishal Verma Reviewed-by: Chao Gao Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Kai Huang --- arch/x86/include/asm/shared/tdx_errno.h | 1 + arch/x86/include/asm/tdx.h | 3 +++ arch/x86/virt/vmx/tdx/tdx.h | 1 + arch/x86/virt/vmx/tdx/tdx.c | 31 +++++++++++++++++++++++++++++= ++ 4 files changed, 36 insertions(+) diff --git a/arch/x86/include/asm/shared/tdx_errno.h b/arch/x86/include/asm= /shared/tdx_errno.h index 3c1e8ce716e3..ee411b360e20 100644 --- a/arch/x86/include/asm/shared/tdx_errno.h +++ b/arch/x86/include/asm/shared/tdx_errno.h @@ -13,6 +13,7 @@ #define TDX_NON_RECOVERABLE_TD_NON_ACCESSIBLE 0x6000000500000000ULL #define TDX_NON_RECOVERABLE_TD_WRONG_APIC_MODE 0x6000000700000000ULL #define TDX_INTERRUPTED_RESUMABLE 0x8000000300000000ULL +#define TDX_SYS_BUSY 0x8000020200000000ULL #define TDX_OPERAND_INVALID 0xC000010000000000ULL #define TDX_OPERAND_BUSY 0x8000020000000000ULL #define TDX_PREVIOUS_TLB_EPOCH_BUSY 0x8000020100000000ULL diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index bf83a974a0d5..15eac89b0afb 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -193,6 +193,8 @@ static inline int pg_level_to_tdx_sept_level(enum pg_le= vel level) return level - 1; } =20 +void tdx_sys_disable(void); + u64 tdh_vp_enter(struct tdx_vp *vp, struct tdx_module_args *args); u64 tdh_mng_addcx(struct tdx_td *td, struct page *tdcs_page); u64 tdh_mem_page_add(struct tdx_td *td, u64 gpa, struct page *page, struct= page *source, u64 *ext_err1, u64 *ext_err2); @@ -224,6 +226,7 @@ static inline void tdx_init(void) { } static inline u32 tdx_get_nr_guest_keyids(void) { return 0; } static inline const char *tdx_dump_mce_info(struct mce *m) { return NULL; } static inline const struct tdx_sys_info *tdx_get_sysinfo(void) { return NU= LL; } +static inline void tdx_sys_disable(void) { } #endif /* CONFIG_INTEL_TDX_HOST */ =20 #endif /* !__ASSEMBLER__ */ diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index dde219c823b4..e2cf2dd48755 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -46,6 +46,7 @@ #define TDH_PHYMEM_PAGE_WBINVD 41 #define TDH_VP_WR 43 #define TDH_SYS_CONFIG 45 +#define TDH_SYS_DISABLE 69 =20 /* * SEAMCALL leaf: diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 1b2d854ba664..1ae558bcca3a 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -1947,3 +1948,33 @@ u64 tdh_phymem_page_wbinvd_hkid(u64 hkid, struct pag= e *page) return seamcall(TDH_PHYMEM_PAGE_WBINVD, &args); } EXPORT_SYMBOL_FOR_KVM(tdh_phymem_page_wbinvd_hkid); + +void tdx_sys_disable(void) +{ + struct tdx_module_args args =3D {}; + u64 ret; + + /* + * Don't loop forever. + * + * - TDX_INTERRUPTED_RESUMABLE guarantees forward progress between + * calls. + * + * - TDX_SYS_BUSY could be returned due to contention with other + * TDH.SYS.* SEAMCALLs, but will lock out *new* TDH.SYS.* SEAMCALLs, + * so that SYS.DISABLE can eventually make progress. + * + * This is a 'destructive' SEAMCALL, in that no other SEAMCALL can be + * run after this until a full reinitialization is done. + */ + do { + ret =3D seamcall(TDH_SYS_DISABLE, &args); + } while (ret =3D=3D TDX_INTERRUPTED_RESUMABLE || ret =3D=3D TDX_SYS_BUSY); + + /* + * Print SEAMCALL failures, but not SW-defined error codes + * (SEAMCALL faulted with #GP/#UD, TDX not supported). + */ + if (ret && (ret & TDX_SW_ERROR) !=3D TDX_SW_ERROR) + pr_err("TDH.SYS.DISABLE failed: 0x%016llx\n", ret); +} --=20 2.53.0 From nobody Fri Apr 3 17:37:49 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A97331E828; Thu, 2 Apr 2026 06:32:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; cv=none; b=nhQQb4o1E+nKvpFO4L0a4kTYI/UoJKaXHH+YVqxSrXILYU554luqqdn46NISwpvIpiMGHw1cSLmoFHT3jDm4NYrUDTfKaSMW/mhjnKS8+OqbV7TpjGXkk7cUmjuIUdL8L8MtEK/bQ1MYONmdcjLS6zY+P82x0n84gECDlrW7nd4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111541; c=relaxed/simple; bh=A9Bu6YW0JJ3sEudHNh+6USELpWk+iSo75GWWP4uYSfg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=feoELae2Sp9kWUr2l6LZlSN6NLFP6CkZqIwVtnAuuEcvKFP+Kq6yQVumHNvAIXttx9Lb1ei01OPIWxXfzNd0WZJ7ypwp9AANeaOWP3Y/YLIzy3C6+jlbpBfWMkdQ6aWrb7i5B3MTSMkTD95KdSM5ki+QS/c6mDZNwjK8ZaY+oxY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RXUGNmxN; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RXUGNmxN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775111540; x=1806647540; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=A9Bu6YW0JJ3sEudHNh+6USELpWk+iSo75GWWP4uYSfg=; b=RXUGNmxN7n1KcFuEnVNI3kzUVwlGA/mXzr6gXV/bpcHRLPPo6XNXxTZ2 lFHQOul81ZrwsK/O0REJIPjKJvkdP6/ecdJpQktJMh9FFXahr8Bv8ywGQ MYrld0Z3b3xsiQ0NT0BFcCc/gkt5kjF0qPpL/DMpcltswzheMYM6yHNrz x4H0v/q02wyrF+19OOcJ6F9ogtKZXTx+635G3qzDfqQj11apYEDI5z5GM 79B5MUDgpDKJ8OYOLNcCkK7fqeO+sCH2x/hoZsFJ94Xc/pK+Y41ZMesPh UGqO5LhUH96kuteVM9TRn5NnK7RUD+MgPEAWPOp2FRgMZ/yOC/cXBp5GU g==; X-CSE-ConnectionGUID: Lu38HsLDSfCFs9+l9KVqaQ== X-CSE-MsgGUID: CiUmStqfReqmlrs7hddTvw== X-IronPort-AV: E=McAfee;i="6800,10657,11746"; a="75884391" X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="75884391" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:20 -0700 X-CSE-ConnectionGUID: oBBhWelHT0aytIgSkK7nLQ== X-CSE-MsgGUID: RwBw8TzZTA+3hXIpDUtHPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="222042386" Received: from vverma7-desk1.amr.corp.intel.com (HELO [192.168.1.200]) ([10.124.223.130]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:19 -0700 From: Vishal Verma Date: Thu, 02 Apr 2026 00:32:04 -0600 Subject: [PATCH v3 4/5] x86/tdx: Disable the TDX module during kexec and kdump Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260402-fuller_tdx_kexec_support-v3-4-34438d7094bf@intel.com> References: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> In-Reply-To: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , Paolo Bonzini Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Vishal Verma , Kai Huang X-Mailer: b4 0.16-dev-ad80c X-Developer-Signature: v=1; a=openpgp-sha256; l=3679; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=A9Bu6YW0JJ3sEudHNh+6USELpWk+iSo75GWWP4uYSfg=; b=owGbwMvMwCXGf25diOft7jLG02pJDJnneAsmRP7s2D9vg2P9+Ue2Ecbmb23dJp48LWe/27Bwo fZulqv9HaUsDGJcDLJiiix/93xkPCa3PZ8nMMERZg4rE8gQBi5OAZjIuT8M/+t/p9w6v/17wMvN jz2ad+2JXMJuJp17YVp8Rx77XQaxmYIM/+yZTb5xT2p8JGc1z8RdyT/Kv/fHe8ebxnwLbxYcVEv PZQQA X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF Use the TDH.SYS.DISABLE SEAMCALL, which disables the TDX module, reclaims all memory resources assigned to TDX, and clears any partial-write induced poison, to allow kexec and kdump on platforms with the partial write errata. On TDX-capable platforms with the partial write erratum, kexec has been disabled because the new kernel could hit a machine check reading a previously poisoned memory location. Later TDX modules support TDH.SYS.DISABLE, which disables the module and reclaims all TDX memory resources, allowing the new kernel to re-initialize TDX from scratch. This operation also clears the old memory, cleaning up any poison. Add tdx_sys_disable() to tdx_shutdown(), which is called in the syscore_shutdown path for kexec. This is done just before tdx_shutdown() disables VMX on all CPUs. For kdump, call tdx_sys_disable() in the crash path before x86_virt_emergency_disable_virtualization_cpu() does VMXOFF. Since this clears any poison on TDX-managed memory, remove the X86_BUG_TDX_PW_MCE check in machine_kexec() that blocked kexec on partial write errata platforms. Co-developed-by: Rick Edgecombe Signed-off-by: Rick Edgecombe Signed-off-by: Vishal Verma Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Kai Huang --- arch/x86/kernel/crash.c | 2 ++ arch/x86/kernel/machine_kexec_64.c | 16 ---------------- arch/x86/virt/vmx/tdx/tdx.c | 1 + 3 files changed, 3 insertions(+), 16 deletions(-) diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index cd796818d94d..623d4474631a 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -38,6 +38,7 @@ #include #include #include +#include #include #include #include @@ -112,6 +113,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs) =20 crash_smp_send_stop(); =20 + tdx_sys_disable(); x86_virt_emergency_disable_virtualization_cpu(); =20 /* diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_k= exec_64.c index 0590d399d4f1..c3f4a389992d 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -347,22 +347,6 @@ int machine_kexec_prepare(struct kimage *image) unsigned long reloc_end =3D (unsigned long)__relocate_kernel_end; int result; =20 - /* - * Some early TDX-capable platforms have an erratum. A kernel - * partial write (a write transaction of less than cacheline - * lands at memory controller) to TDX private memory poisons that - * memory, and a subsequent read triggers a machine check. - * - * On those platforms the old kernel must reset TDX private - * memory before jumping to the new kernel otherwise the new - * kernel may see unexpected machine check. For simplicity - * just fail kexec/kdump on those platforms. - */ - if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) { - pr_info_once("Not allowed on platform with tdx_pw_mce bug\n"); - return -EOPNOTSUPP; - } - /* Setup the identity mapped 64bit page table */ result =3D init_pgtable(image, __pa(control_page)); if (result) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 1ae558bcca3a..c0c6281b08a5 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -259,6 +259,7 @@ static void tdx_shutdown_cpu(void *ign) =20 static void tdx_shutdown(void *ign) { + tdx_sys_disable(); on_each_cpu(tdx_shutdown_cpu, NULL, 1); } =20 --=20 2.53.0 From nobody Fri Apr 3 17:37:49 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB1F6372ECC; Thu, 2 Apr 2026 06:32:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111543; cv=none; b=QCQoVMv4n0CmMs7gkr0zemRRHt1Fpldu7avEYhWccDpzgysOFNZfLfqu1a1a1KBjAY++v/fPW5sUl/7YdDhshDoeJyICsOISSHNYl4ZZOXPo6ja03AW8Cg9TF5rrWl9C7QWfEpm1LT61Ahny/+LC3dPkghZ/pcenq+kqbQDQFkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775111543; c=relaxed/simple; bh=v4RCp3DgZwg8fGD7TLVSrb+Thlquly9ZhJsd1ten7VU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=lKppfVg2rsz6k3hoPLc3kaB5Ic4hOYBSk4eKii256XQC6R5qzWUqmDPyMymoaRyXWIwmH8CP19voUSl3UgihTTeM/6RPUX1vqrq7LPjxJxExMgyDg+A3dUYUDez6gLwGX6FvZEKwngGhalX6xfqE36+YPYrgc+0DzJ10o1kqzJ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=dmRJPZga; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="dmRJPZga" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775111542; x=1806647542; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=v4RCp3DgZwg8fGD7TLVSrb+Thlquly9ZhJsd1ten7VU=; b=dmRJPZgacbj0osqniiwk4nP27rGsuZ0KhueRgJgbZQVY28RdCMijdbqP jgog34wu+fYiD+pjFrkm7sPBIycKABa9jD8XVoXmImYQPUG8P4AcNGewR ulVguYIm3KzQR6z2YVqYzP147VzAhknX/6jBwrKRmnsvuMtUu3A2pSbYn Za92QG1FYW8Fw4SDKSLvWF5NnQRoviWq64FNq/P15tc3z+CnrJ6L6gvV6 8Xxi/d7OcaJ2zb4TnEZd9Lwp0q1tFr8VR+lQi6/VLhodHokk3+1bCu4eX tbYgPv3f+Uv8jJAUEW4w51GbelUqNoAwgOOye1ZH+fPNn5y1hR3O2o3Wd w==; X-CSE-ConnectionGUID: 6ZvrQzVDQQqjscvihK3FzA== X-CSE-MsgGUID: p7mSd284SkmyJWND8Ikgcg== X-IronPort-AV: E=McAfee;i="6800,10657,11746"; a="75884399" X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="75884399" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:20 -0700 X-CSE-ConnectionGUID: 0qbgdqQHTNOnsukidh3Pgw== X-CSE-MsgGUID: cX5hRaTERj+ylDVSspsfAw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,155,1770624000"; d="scan'208";a="222042389" Received: from vverma7-desk1.amr.corp.intel.com (HELO [192.168.1.200]) ([10.124.223.130]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 23:32:19 -0700 From: Vishal Verma Date: Thu, 02 Apr 2026 00:32:05 -0600 Subject: [PATCH v3 5/5] x86/virt/tdx: Remove kexec docs Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260402-fuller_tdx_kexec_support-v3-5-34438d7094bf@intel.com> References: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> In-Reply-To: <20260402-fuller_tdx_kexec_support-v3-0-34438d7094bf@intel.com> To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , Paolo Bonzini Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Vishal Verma , Kai Huang X-Mailer: b4 0.16-dev-ad80c X-Developer-Signature: v=1; a=openpgp-sha256; l=1361; i=vishal.l.verma@intel.com; h=from:subject:message-id; bh=1Dl/GZsjCRJsUxH+cy4bLVKZfjRWEh+bCymAu8RNUM0=; b=owGbwMvMwCXGf25diOft7jLG02pJDJnneAs6Pi20KT51sSVtatV2XobCA8tbC8JS3LhCPmmuS NfcdlOqo5SFQYyLQVZMkeXvno+Mx+S25/MEJjjCzGFlAhnCwMUpABMxM2JkOL38kd+85yvl9jSU Gs7yn2u3/fVax8MzD52bfmbKHeEWnkRGht1v8/+HnVfiPqzOvd72TtUa97yy2z/1Q8Uenomdf9a ulRcA X-Developer-Key: i=vishal.l.verma@intel.com; a=openpgp; fpr=F8682BE134C67A12332A2ED07AFA61BEA3B84DFF From: Rick Edgecombe Recent changes have removed the hard limitations for using kexec and TDX together. So remove the section in the TDX docs. Users on partial write erratums will need an updated TDX module to handle the rare edge cases. The docs do not currently provide any guidance on recommended TDX module versions, so don't keep a whole section around to document this interaction. Signed-off-by: Rick Edgecombe Signed-off-by: Vishal Verma Reviewed-by: Kiryl Shutsemau (Meta) Acked-by: Kai Huang --- Documentation/arch/x86/tdx.rst | 7 ------- 1 file changed, 7 deletions(-) diff --git a/Documentation/arch/x86/tdx.rst b/Documentation/arch/x86/tdx.rst index ff6b110291bc..1a3b5bac1021 100644 --- a/Documentation/arch/x86/tdx.rst +++ b/Documentation/arch/x86/tdx.rst @@ -138,13 +138,6 @@ If the platform has such erratum, the kernel prints ad= ditional message in machine check handler to tell user the machine check may be caused by kernel bug on TDX private memory. =20 -Kexec -~~~~~~~ - -Currently kexec doesn't work on the TDX platforms with the aforementioned -erratum. It fails when loading the kexec kernel image. Otherwise it -works normally. - Interaction vs S3 and deeper states ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 --=20 2.53.0