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

[Duan, Zhenzhong]

>-----Original Message-----
>From: Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx>
>Subject: Re: [RFC PATCH 06/15] virt: tdx-guest: Support TDI bind and unbind
>operations
>
>On Thu, 2026-11-05 at 04:37 +0000, Duan, Zhenzhong wrote:
>>
>> > -----Original Message-----
>> > From: Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx>
>> > Subject: Re: [RFC PATCH 06/15] virt: tdx-guest: Support TDI bind and
>unbind
>> > operations
>> >
>> > On Wed, 2026-11-04 at 08:59 +0000, Duan, Zhenzhong wrote:
>> > > > I'm not clear whose fault this is.
>> > >
>> > > Host side fault, e.g., a malicious VMM does nothing in UNBIND TDCM
>> > hypercall.
>> >
>> > If the host *can* always handle this, but just doesn't, then I wonder
>how
>> > much
>> > effort we should spend to on handling it. We can't protect against TD
>DOS
>> > by the
>> > host, so don't try. So this seems similar.
>>
>> Fair point, I was overthinking this.
>
>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.

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.