Re: [PATCH v2 07/17] x86/virt/tdx: Initialize Quoting extension

[Peter Fang <peter.fang@intel.com>]

On Thu, Jun 18, 2026 at 08:50:16AM +0000, sashiko-bot@kernel.org wrote:
> 
> > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> > index 4d2940f4538a2..06c42b86b05e8 100644
> > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> [ ... ]
> > +/* Initialize quoting extension */
> > +static __init int tdx_quote_init(void)
> > +{
> > +	struct tdx_module_args args = {};
> > +	u64 r;
> > +
> > +	do {
> > +		r = seamcall(TDH_QUOTE_INIT, &args);
> > +	} while (r == TDX_INTERRUPTED_RESUMABLE);
> > +
> > +	if (r != TDX_SUCCESS)
> > +		return -EFAULT;
> 
> [Severity: High]
> Does this discard the actual SEAMCALL error code? By returning -EFAULT
> here, the specific hardware error information from TDH_QUOTE_INIT is lost,
> which might make debugging initialization failures difficult.

Yilun did a pretty decent analysis of this in [1]. There really isn't
much the host can do if this fails, so it seems like a reasonable
tradeoff to just make sure there's a record of this in the kernel log.

> 
> > +
> > +	return 0;
> > +}
> > +
> > +static __init void init_tdx_quoting_extension(void)
> > +{
> > +	int ret;
> > +
> > +	if (tdx_addon_feature0 & TDX_FEATURES0_QUOTE) {
> > +		ret = tdx_quote_init();
> > +		WARN_ON_ONCE(ret);
> 
> [Severity: High]
> The commit message explicitly states that quoting is an optional feature
> and initialization failures shouldn't cause TDX bringup to fail.
> 
> Is WARN_ON_ONCE() too aggressive here? On systems configured with
> panic_on_warn=1 (which is common in many environments), this will
> trigger a kernel panic instead of gracefully falling back to the
> userspace flow.

Having a splat here is to draw the user's attention. Patch 13 sets the
TDX_FEATURES0_QUOTE bit only if the TDX module reports support for it.
Advertising such support but then failing to initialize it is very
likely a TDX module bug. Since attestation is pretty important to TDX
security, I think using WARN_ON_ONCE() here should be okay, and the
backtrace should be enough to describe the failure.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618081355.3253581-1-yilun.xu@linux.intel.com?part=7
> 

[1] https://lore.kernel.org/kvm/ajq8RFjv2YFghvQp@yilunxu-OptiPlex-7050/