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

[Alexey Kardashevskiy <aik@amd.com>]

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,


-- 
Alexey