From: "Huang, Kai" <kai.huang@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
"kas@kernel.org" <kas@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"Verma, Vishal L" <vishal.l.verma@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tglx@kernel.org" <tglx@kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/5] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE
Date: Mon, 23 Mar 2026 22:40:46 +0000 [thread overview]
Message-ID: <d783c07ce3d6bf7477eaee3b892a3f007bd291e6.camel@intel.com> (raw)
In-Reply-To: <20260323-fuller_tdx_kexec_support-v2-3-87a36409e051@intel.com>
On Mon, 2026-03-23 at 14:59 -0600, Vishal Verma wrote:
> 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.
>
> Co-developed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
>
Acked-by: Kai Huang <kai.huang@intel.com>
next prev parent reply other threads:[~2026-03-23 22:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 20:59 [PATCH v2 0/5] Fuller TDX kexec support Vishal Verma
2026-03-23 20:59 ` [PATCH v2 1/5] x86/tdx: Move all TDX error defines into <asm/shared/tdx_errno.h> Vishal Verma
2026-03-24 9:49 ` Chao Gao
2026-03-31 19:30 ` Sean Christopherson
2026-03-31 21:46 ` Edgecombe, Rick P
2026-03-23 20:59 ` [PATCH v2 2/5] x86/virt/tdx: Pull kexec cache flush logic into arch/x86 Vishal Verma
2026-03-24 10:03 ` Chao Gao
2026-03-30 11:42 ` Kiryl Shutsemau
2026-03-31 19:22 ` Sean Christopherson
2026-03-31 22:21 ` Edgecombe, Rick P
2026-03-31 23:04 ` Sean Christopherson
2026-03-31 23:29 ` Edgecombe, Rick P
2026-04-01 15:03 ` Dave Hansen
2026-04-01 17:42 ` H. Peter Anvin
2026-04-01 18:12 ` Sean Christopherson
2026-04-01 18:30 ` Dave Hansen
2026-03-23 20:59 ` [PATCH v2 3/5] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE Vishal Verma
2026-03-23 21:54 ` Verma, Vishal L
2026-03-23 22:40 ` Huang, Kai [this message]
2026-03-24 10:18 ` Chao Gao
2026-03-30 11:58 ` Kiryl Shutsemau
2026-03-30 19:25 ` Edgecombe, Rick P
2026-03-31 12:18 ` Kiryl Shutsemau
2026-03-31 18:22 ` Verma, Vishal L
2026-03-31 21:36 ` Edgecombe, Rick P
2026-04-01 9:26 ` Kiryl Shutsemau
2026-04-01 14:24 ` Dave Hansen
2026-03-23 20:59 ` [PATCH v2 4/5] x86/tdx: Disable the TDX module during kexec and kdump Vishal Verma
2026-03-23 22:41 ` Huang, Kai
2026-03-30 12:03 ` Kiryl Shutsemau
2026-03-23 20:59 ` [PATCH v2 5/5] x86/virt/tdx: Remove kexec docs Vishal Verma
2026-03-23 22:41 ` Huang, Kai
2026-03-30 12:04 ` Kiryl Shutsemau
2026-04-22 12:45 ` [PATCH] x86/tdx, KVM: fix HKID leak when kexec is initiated with active TDs Nowicki, Robert
2026-04-22 13:14 ` Sean Christopherson
[not found] ` <CH3PR11MB843450CBD154D42B31D15E93832D2@CH3PR11MB8434.namprd11.prod.outlook.com>
2026-04-22 13:34 ` Sean Christopherson
2026-04-22 14:29 ` Edgecombe, Rick P
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=d783c07ce3d6bf7477eaee3b892a3f007bd291e6.camel@intel.com \
--to=kai.huang@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=vishal.l.verma@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.