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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 10, 2026 at 10:25:07PM +0000, Edgecombe, Rick P wrote:
> 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.

Any failure to attest should just propogate to guest userspace and
userspace wil fail the attestation and not enable the device. This is
fine.

All failure classes, including the cases where the guest is checking
digests/etc to confirm the host has done the right thing can work like
this.

> 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.

It does not seem necessary to me, userspace is responsible. Since no
device evidence could possibly have been logged the VM would fail
attestation anyhow.

Jason