RE: [RFC PATCH 03/15] x86/tdx: Add TDG.TDI.RD module call wrapper for TDX Connect

[Duan, Zhenzhong]

>-----Original Message-----
>From: Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx>
>Subject: Re: [RFC PATCH 03/15] x86/tdx: Add TDG.TDI.RD module call wrapper
>for TDX Connect
>
>On Tue, 2026-10-27 at 06:22 +0000, Duan, Zhenzhong wrote:
>
>
>>
>>
>> > -----Original Message-----
>> > From: Li, Xiaoyao <[xiaoyao.li@xxxxxxxxx](mailto:xiaoyao.li@xxxxxxxxx)>
>> > Subject: Re: [RFC PATCH 03/15] x86/tdx: Add TDG.TDI.RD module call
>wrapper
>> > for TDX Connect
>> >
>> > On 9/24/2026 12:10 PM, Zhenzhong Duan wrote:
>> >
>> > > Introduce wrapper tdx_mcall_tdi_read() to provide tdx-guest driver
>with a
>> > > standard interface for querying specific metadata fields from a
>target
>> > > Trust Device Interface Control Structure (TDI_CS).
>> > >
>> > > Explicitly mapping architectural TDX error codes into Linux POSIX
>errno
>> > > with two helpers, introducing tdx_mcall_to_errno() to handle general
>> > > module calls, while introducing tdx_mcall_tdi_to_errno() specifically
>for
>> > > TDI related module calls.
>> >
>> >
>> > Set aside why mapping architectural TDX error codes into Linux POSIX
>errno
>> > is
>> > needed and what it brings, I think the common enabling order is one
>prep
>> > patch
>> > to introduce tdx_mcall_to_errno() and turn existing users to use it.
>Then
>> > this
>> > patch introduces tdx_mcall_tdi_to_errno() to use it as well.
>>
>>
>> Ideally yes, we follow this way so that reviewers can focus on the core
>> implementation and defer cleanup to a later series. We can revisit this
>> if that rule changes.
>
>
>...you are going to have justify the whole tdx_mcall_tdi_to_errno() thing
>first
>as discussed in the other patch.

Well, tdx_mcall_tdi_to_errno() just translates TDX module status codes
nto Linux errno values. -EBUSY is the one that can indicate contention;
other errors are passed back to userspace.

I went through the locks taken by each TDCALL and SEAMCALL and checked
which operations can contend in the current flow. I found one case we
need to handle now: concurrent TDG.TDI.MMIO.ACCEPT calls for TDIs under
the same IOMMU can contend for its exclusive lock.

A future TDG.TDI.RD read of the attestation-info-hash field could also
contend for the IOMMU lock. We don't need to handle that until we add
guest attestation.

Since retries are only needed for TDG.MMIO.ACCEPT and, later, that specific
TDG.TDI.RD field, I think it's cleaner to do retry in those call sites
rather than in wrapper.

>
>
>
>>
>> >
>> >
>> > > Unlike TDG.VP.VMCALL based hypercalls which communicate with the
>host,
>> > > TDG.TDI.RD is a module call (mcall) that communicates directly with
>the
>> > > TDX module. This distinction is reflected in the tdx_mcall_ naming
>> > > prefix, as opposed to tdx_hcall_ used for host-directed hypercalls.
>> >
>> >
>> > I would say this paragraph is not needed. It's not the first patch to
>> > introduce
>> > hcall and mcall.
>>
>>
>> I think we need this brief explanation for the hcall/mcall naming
>distinction.
>> Not all are familiar with TDX and know what hcall/mcall means.
>> I'm open on this, if more people think no need, I'll remove this
>paragraph.
>
>I think it's ok. Maybe make it clearer that this is explaining the pre-
>existing
>naming schemes (which I think are a bit confusing since they all go through
>the
>module).

Will rephase as:

"TDG.TDI.RD is handled directly by the TDX module. By contrast,
TDG.VP.VMCALL passes through the module to reach the VMM. The existing
tdx_mcall_ and tdx_hcall_ prefixes distinguish these two paths."