RE: [RFC PATCH 02/15] x86/tdx: Add TDCM hypercall wrapper for TDX Connect

[Duan, Zhenzhong]

>-----Original Message-----
>From: Nikolay Borisov <nik.borisov@xxxxxxxx>
>Subject: Re: [RFC PATCH 02/15] x86/tdx: Add TDCM hypercall wrapper for TDX
>Connect
>
>
>
>On 24.09.26 г. 7:10 ч., Zhenzhong Duan wrote:
>> TDX Connect is a TDX feature that enables secure device assignment,
>> allowing a TDX guest to directly interact with TEE-IO capable devices.
>>
>> The TEE-IO Device Control and Management (TDCM) hypercall
>> (TDG.VP.VMCALL<TDCM>, defined in TDX GHCI v2.0 specification) is the
>> primary interface through which a TDX guest issues device management
>> commands to the host. The host processes these commands and returns
>> responses via a shared memory buffer.
>
>This patch contradicts what's going in patch 5. Because you make it
>sound as if TDCM is yet another leaf of VP.VMCALL, but then in patch 5
>you introduce the polling code to read the result. And there is not
>enough information in the changelogs to understand why this added
>complexity is needed. Isn't TDCM handled synchronously by the VMM as the
>rest of the tdcalls, is it perhaps handled by TDX NRX module?

TDG.VP.VMCALL<TDCM> is the leaf used to submit a TDCM request. The VMM’s
return from that VMCALL acknowledges the request; it does not 
necessarily mean the device-management operation has completed. GHCI 
defines asynchronous completion for potentially long-running operations.

GHCI describes polling the shared status and event notification as 
completion mechanisms. This series uses polling with a timeout; it does 
not use event notification. TDCM is not implemented by the NRX module, 
although some host-side operations initiated by TDCM may use NRX 
internally.

I’ll clarify the submission-versus-completion distinction in this 
patch’s changelog and explain the polling choice in patch 5.

Thanks
Zhenzhong