From: Kiryl Shutsemau <kas@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Challvy Tee <challvy.tee@gmail.com>,
x86@kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
regressions@lists.linux.dev, stable@vger.kernel.org,
dave.hansen@linux.intel.com, rick.p.edgecombe@intel.com,
vishal.l.verma@intel.com, kai.huang@intel.com, seanjc@google.com
Subject: Re: [PATCH v3] x86/virt/tdx: Skip TDH.SYS.DISABLE if the TDX module is not initialized
Date: Fri, 30 Oct 2026 16:26:35 +0000 [thread overview]
Message-ID: <auTExTAMoaKKjBrb@thinkstation> (raw)
In-Reply-To: <939b4cc7-5c7f-429d-a9be-830aa1c53ac5@intel.com>
On Fri, Oct 30, 2026 at 09:13:12AM -0700, Dave Hansen wrote:
> On 10/30/26 08:48, Challvy Tee wrote:
> > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> > @@ -2321,6 +2321,9 @@ void tdx_sys_disable(void)
> > struct tdx_module_args args = {};
> > u64 ret;
> >
> > + if (!tdx_module_state.initialized)
> > + return;
>
> NAK from me on this.
>
> If SEAMCALL is fatal then we need stronger barriers on the generic paths
> to SEAMCALLs themselves, not one-off patches of the sites.
I don't think the generic path is the right place for it. For every
other caller, reaching a SEAMCALL on a non-TDX system means something
went wrong higher up, and we want to see it. A check there that quietly
returns an error hides that. Making it WARN would catch it, but then the
crash path would still need its own check before the call.
So gate the call on X86_FEATURE_TDX_HOST_PLATFORM, the same way
paddr_is_tdx_private() does.
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-10-30 16:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <auM3KKutfutAqgWG@thinkstation>
2026-10-30 15:48 ` [PATCH v3] x86/virt/tdx: Skip TDH.SYS.DISABLE if the TDX module is not initialized Challvy Tee
2026-10-30 16:13 ` Dave Hansen
2026-10-30 16:26 ` Kiryl Shutsemau [this message]
2026-10-30 16:38 ` Dave Hansen
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=auTExTAMoaKKjBrb@thinkstation \
--to=kas@kernel.org \
--cc=challvy.tee@gmail.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox