Return `-EBUSY` from tdx_mcall_get_report0() when `TDG.MR.REPORT` returns
`TDCALL_OPERAND_BUSY`. This enables the caller to retry obtaining a
TDREPORT later if another VCPU is extending an RTMR concurrently.

Signed-off-by: Cedric Xing <cedric.xing@intel.com>
---
 arch/x86/coco/tdx/tdx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index b042ca74bcd3..c94e0061fe53 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -114,8 +114,8 @@ static inline u64 tdg_vm_wr(u64 field, u64 value, u64 mask)
  * v1.0 specification for more information on TDG.MR.REPORT TDCALL.
  * It is used in the TDX guest driver module to get the TDREPORT0.
  *
- * Return 0 on success, -EINVAL for invalid operands, or -EIO on
- * other TDCALL failures.
+ * Return 0 on success, -EINVAL for invalid operands, -EBUSY for busy
+ * operation or -EIO on other TDCALL failures.
  */
 int tdx_mcall_get_report0(u8 *reportdata, u8 *tdreport)
 {
@@ -130,6 +130,8 @@ int tdx_mcall_get_report0(u8 *reportdata, u8 *tdreport)
 	if (ret) {
 		if (TDCALL_RETURN_CODE(ret) == TDCALL_INVALID_OPERAND)
 			return -EINVAL;
+		else if (TDCALL_RETURN_CODE(ret) == TDCALL_OPERAND_BUSY)
+			return -EBUSY;
 		return -EIO;
 	}
 

-- 
2.43.0

Cedric Xing wrote:
> Return `-EBUSY` from tdx_mcall_get_report0() when `TDG.MR.REPORT` returns
> `TDCALL_OPERAND_BUSY`. This enables the caller to retry obtaining a
> TDREPORT later if another VCPU is extending an RTMR concurrently.

Can this not be prevented by proper locking? Otherwise this type of
collision sounds like a kernel bug, not something that should escape to
userspace.

I.e. userspace can not reasonably know when it is safe to retry, so take
locks to ensure forward progress.

On 4/9/2025 12:13 AM, Dan Williams wrote:
> Cedric Xing wrote:
>> Return `-EBUSY` from tdx_mcall_get_report0() when `TDG.MR.REPORT` returns
>> `TDCALL_OPERAND_BUSY`. This enables the caller to retry obtaining a
>> TDREPORT later if another VCPU is extending an RTMR concurrently.
> 
> Can this not be prevented by proper locking? Otherwise this type of
> collision sounds like a kernel bug, not something that should escape to
> userspace.
> 
Yes, -EBUSY should never happen with proper locking, which however is 
implemented in the upper layer.

Similarly, -EINVAL will also indicate a kernel bug but is left for the 
upper layer to handle.

> I.e. userspace can not reasonably know when it is safe to retry, so take
> locks to ensure forward progress.
tdx-guest does WARN() on errors. There are no other users of this 
function currently. Returning an error, however, will allow different 
error handling in the future (e.g., retry instead of WARN on -EBUSY).