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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Nov 12, 2026 at 09:50:12PM +1100, Alexey Kardashevskiy wrote:
> On 12/11/26 10:05, Tian, Kevin wrote:
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > Sent: Wednesday, November 11, 2026 11:00 PM
> > > 
> > > On Wed, Nov 11, 2026 at 09:44:42AM +0000, Tian, Kevin wrote:
> > > 
> > > > The interesting case is about such failures after attest e.g. unlock
> > > > which is supposed to be a void operation. Maybe we don't need do
> > > > anything special in tsm core - the secure firmware maintains the
> > > > state machine so future lock will fail if the current state is not
> > > > unlocked.
> > > 
> > > unlock can't fail, we have no way to cope with that.
> > > 
> > > If unlock does not result in the MMMIO returned to host control then
> > > the system will surely MCE.
> > > 
> > > This should have nothing to do with a crashed device, the disposition
> > > of the MMIO is under TDX module control, revert it back to host and
> > > accept you get AERs for the incorrect T= bit if the device isn't syncd.
> > > 
> > > The OS would have to kill the SPDM session and FLR the PF to bring it
> > > all back.
> > > 
> > 
> > Agree but we were talking about different scenarios. Your description
> > is about real device hang, while mine is about unlock failure from
> > guest p.o.v. which can be caused by either hardware issue or host
> > software issues. Or a malicious host may report success w/o actually
> > doing anything.
> > 
> > My point was that the guest can just assume unlock always succeed
> > and rely on the secure firmware to ensure future operations blocked
> > in case of incomplete unlock. We don't need to do anything special
> > within the guest tsm core upon GHCI unlock errors.
> 
> If the guest asked for unlock() and the secure fw failed to do so
> and reported an error (which my hosts cannot hide), then the guest
> memory is still exposed (via DMA) to some unwanted thing. If
> anything - it is time to panic() imho. Thanks,

It is completely bad FW design. If you ask for unlock it cannot fail
in a way that DMA is still enabled. You should still clear the sDTE
and that should be a non-failable operation.

Jason