Re: [RFC PATCH 06/15] virt: tdx-guest: Support TDI bind and unbind operations

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2026-11-10 at 15:57 -0400, Jason Gunthorpe wrote:
> On Tue, Nov 10, 2026 at 06:55:41PM +0000, Edgecombe, Rick P wrote:
> 
> > Additionally, we should probably see if Jason has any opinion on the types of
> > errors that guest TSM would like to handle.
> 
> Not at this point :\ And perhaps not at all.
> 
> Most of this stuff will end up routing through userspace so it has to
> be compressed into a errno.'
> 
> The various VMM to guest specs like GHCI are going to define their own
> contracts, and it is up to Intel to ensure that the full route from
>   this code -> attestation subsystem -> uapi -> vmm -> GHCI
> 
> Preserves whatever semantics have been defined in the spec.
> 
> I don't know the answer to the EBUSY question, other than
> TSM/attestation will return that to userspace. Can your VMM and GHCI
> sort it out?

Kevin and Yilun are analyzing what kind of errors we should expect the VMM to
handle. But some of the cases Zhenzhong listed seem like they could be
situations trusted IO guests could encounter generally. Like the example
"[device] firmware hangs during lock/unlock". In that case unification in TSM
could be nice.

For errors that indicate uncooperative or buggy host, we elsewhere warn in the
TDX wrappers. But in coco, not handling an error in the caller can be an avenue
to attack the guest. So I guess we would commonly need to handle these errors in
the callers.

Zhenzhong had previously suggested a bool to set a device as bugged for the
purpose of trying to continue guest execution as well as possible in the face of
host issues. I'm wary of picking up any complexity to try to pursue the goal of
niceness in the face of host bugs. But now I'm wondering if something like that
might be a good way to have to think less about security aspects. So we could
return any unexpected errors to userspace, but bug the device on the way out.