Re: [PATCH 3/4] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE

[Edgecombe, Rick P]

On Tue, 2026-03-17 at 09:47 +0000, Kiryl Shutsemau wrote:
>  We debated checking the feature bit before allowing kexec, but decided it was
> > simpler to just blindly call and ignore the errors. The reasoning was that this
> > is already a somewhat exotic scenario being addressed, and future modules will
> > have the feature. So maintaining a check for the feature bit only helps a little
> > bit, for a short time. And then only if the user would rather have kexec blocked
> > than attempt it. Do you think it is worth it?
> 
> No, I see very limited reason to support stale TDX modules. Users are
> expected to keep the module up-to-date, so skipping enumeration should
> be okay. But it deserves explanation in the commit message or a comment.

Ok.

> 
> > > 
> > > Silently ignore any other errors?
> > 
> > Do you think it's worth a warn? There are a couple other considerations.
> >    - Kai brought up offline that we should handle TDX_SYS_BUSY here too.
> >    - Previous kexec patches had trouble solving races around tdx enabling. So we
> > have to handle the seamcall failures.
> > 
> > So we have to exclude a few different errors in different ways. And then the
> > warn worthy error codes either don't impact anything, or the new kernel will
> > fail to initialize the TDX module and give notice there.
> 
> The delayed error is harder to debug. It can be useful to leave a
> breadcrumbs.

Ok, we can parse the errors.

> 
> Also, do we want to make try_init_module_global() return failure after
> tdx_sys_disable()? I guess, TDH_SYS_LP_INIT will fail anyway, so it
> shouldn't matter.

Yea, a side effect of TDH.SYS.DISABLE is that it blocks other seamcalls while it
is executing. I guess the scenario here is TDX init racing with kexec.

But in general if TDX is disabled while any TDX stuff is running, the seamcalls
will be surprised. This is not fully related to TDH.SYS.DISABLE, because VMXOFF
will also cause similar SEAMCALL failures. Each SEAMCALL path would need to
handle the rug pull. And probably we need to balance harmless noise against the
code it takes to be quieter.

try_init_module_global() is different in that it's kernel side code that gets
confused, but I'm not sure how it could be handled in a non-racy way either.
So... I'd think to leave it. Maybe what we really need is a big block comment
about TDX enable/disable lifecycle quirks.