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 Thu, 2026-09-24 at 12:10 +0800, Zhenzhong Duan wrote:
>> -/* TDX Module call error codes */
>> -#define TDCALL_RETURN_CODE(a)	((a) >> 32)
>> -#define TDCALL_INVALID_OPERAND	0xc0000100
>> -#define TDCALL_OPERAND_BUSY	0x80000200
>> -
>>  #define TDREPORT_SUBTYPE_0	0
>>
>>  static atomic_long_t nr_shared;
>> diff --git a/arch/x86/coco/tdx/tdx_connect.c
>b/arch/x86/coco/tdx/tdx_connect.c
>> index 0c6ca650771a..1409b1a30cc6 100644
>> --- a/arch/x86/coco/tdx/tdx_connect.c
>> +++ b/arch/x86/coco/tdx/tdx_connect.c
>> @@ -8,6 +8,17 @@
>>  #include <asm/tdx.h>
>>  #include <linux/mm.h>
>>
>> +static inline int tdx_mcall_tdi_to_errno(u64 ret)
>> +{
>> +	switch (TDCALL_RETURN_CODE(ret)) {
>> +	case TDCALL_TDI_NOT_PRESENT:
>> +	case TDCALL_TDI_INVALID_METADATA:
>> +		return -ENODEV;
>> +	default:
>> +		return tdx_mcall_to_errno(ret);
>> +	}
>> +}
>> +
>>
>
>...
>
>>
>> +/* TDX Module call error codes */
>> +#define TDCALL_RETURN_CODE(a)		((a) >> 32)
>> +#define TDCALL_INVALID_OPERAND		0xc0000100
>> +#define TDCALL_OPERAND_BUSY		0x80000200
>> +#define TDCALL_TDI_NOT_PRESENT		0xc0000f40
>> +#define TDCALL_TDI_INVALID_METADATA	0xc0000f41
>> +
>> +static inline int tdx_mcall_to_errno(u64 ret)
>> +{
>> +	switch (TDCALL_RETURN_CODE(ret)) {
>> +	case TDCALL_INVALID_OPERAND:
>> +		return -ENXIO;
>> +	case TDCALL_OPERAND_BUSY:
>> +		return -EBUSY;
>> +	default:
>> +		return -EIO;
>> +	}
>> +}
>
>Very few of the other tdcalls check the errors, which is a bit surprising. This
>now introduces a generic helper to handle them, but just uses it for the TDI
>calls. Is the intention to use this for the other "mcalls"?

Yes, I plan we will have a cleanup patch to use the generic helper for other mcalls in the future.

>
>But I wonder if something is lost in handling these all by default. Don't we
>need to consider each error? For example, if accept gets a busy and we toss this
>back. Is the caller supposed to retry? Does it expect to? Or should we do
>something to avoid the busy in the first place? We need to at least examine each
>possible error condition as part of the implementation.

Yes, the current mcall use cases actually don't check for busy returns, so I do
the same in this series. I'm operating on the assumption that TD guests are
implicitly designed to prevent the TDX module contention that triggers a
busy state.

For other TDX errors, we don't deeply differentiate between them. To keep things
clean, we only map specific errno values to the TDX errors which are more common.

Thanks
Zhenzhong