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

[Nikolay Borisov <nik.borisov@suse.com>]

On 14.10.26 г. 9:19 ч., Duan, Zhenzhong wrote:
> 
> 
>> -----Original Message-----
>> From: Nikolay Borisov <nik.borisov@suse.com>
>> 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.

> 
> 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?

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