From nobody Fri Apr 3 19:17:59 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