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 14.10.26 г. 9:19 ч., Duan, Zhenzhong wrote:
>>
>>
>>> -----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.
>
>But this is essentially an implementation detail, and currently we don't
>have the host implementation. In that case this choice must be spelled out.

Oh, we don't make a choice for host implementation. Host may complete the
operation and set the final status before returning from the VMCALL, or return
while it is still pending. The guest handles either case: it checks the status after
the VMCALL and polls with a timeout only if completion is pending.

>
>>
>> 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.
>
>Right, those operation falls within the TDX connect spec. And TDCM is
>just a subset of the VP.VMCALL interface used for tdx connect
>management, in that sense it's not a "separate entity" i.e a discrete
>module but just a collection of functionality, implemented in the VMM?

Yes.