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

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

On Fri, 2026-11-06 at 03:03 +0000, Duan, Zhenzhong wrote:
> > 
> > So is this only a bad host behavior? Or something where we could expect in
> > practice the host will not be able to handle it, and at the same time, want
> > to
> > keep the guest running?
> 
> I used a misbehaving VMM only as an example. Failures can also happen
> with a cooperative host, for example if the device becomes unavailable
> after a host-side administrative action, or if its firmware hangs during
> lock/unlock.

We need to characterize the failures we are handling. Anything that we want to
hand back to TSM to handle we should discuss as part of the TSM subsystem work.
We also need to ask whether the host should be handling any of these errors.

I think for VMM bugs, we should not try to handle them in the guest in order to
keep it running. In fact some security conscious users may prefer to have the
guest stop working if strange behavior is noticed. But in any case, bugs should
be fixed and not grow code to work around them in other components.

If there are scenarios that are more RAS-type in nature, where HW breaks, then
I'd think this is a more advanced capability. I'd think we should prefer to punt
on the ability to have the guest survive rare malfunctions if we can for initial
support.

As I explained up the thread, you need to evaluate the concrete scenarios we are
handling and make the case for which component in the guest should handle it.
And what level of abstraction is appropriate for any erros reported to TSM.

> 
> These failures need not prevent the rest of the guest from running.
> If the host reports a TDCM error, the guest propagates it to userspace
> through the sysfs unlock operation.
> 
> Keeping the guest running is therefore useful in these cases, even
> if the affected device is no longer usable.
> 
> If a host-side failure cannot be reported to the guest and makes
> continued execution unsafe, e.g., device AER error, the host could
> terminate the guest.