try_accept_one() treats any non-zero return from __tdcall() as a
failure. However, per the TDX Module Base Spec (Table SEPT Walk Cases),
TDG.MEM.PAGE.ACCEPT returns a non-zero status code with bit 63 clear
when the target page is already in MAPPED state (i.e., already
accepted). This is a "success-with-warning" -- the page is usable and no
action is needed.

Check only bit 63 (TDX_ERROR) to distinguish real errors from
success-with-warning returns, rather than treating all non-zero values
as failures.

Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 arch/x86/coco/tdx/tdx-shared.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/coco/tdx/tdx-shared.c b/arch/x86/coco/tdx/tdx-shared.c
index 1655aa56a0a51..24983601a2ded 100644
--- a/arch/x86/coco/tdx/tdx-shared.c
+++ b/arch/x86/coco/tdx/tdx-shared.c
@@ -35,7 +35,7 @@ static unsigned long try_accept_one(phys_addr_t start, unsigned long len,
 	}
 
 	args.rcx = start | page_size;
-	if (__tdcall(TDG_MEM_PAGE_ACCEPT, &args))
+	if (__tdcall(TDG_MEM_PAGE_ACCEPT, &args) & TDX_ERROR)
 		return 0;
 
 	return accept_size;

-- 
2.53.0

On Tue, 2026-03-24 at 19:21 +0400, Marc-André Lureau wrote:
> try_accept_one() treats any non-zero return from __tdcall() as a
> failure. However, per the TDX Module Base Spec (Table SEPT Walk Cases),
> TDG.MEM.PAGE.ACCEPT returns a non-zero status code with bit 63 clear
> when the target page is already in MAPPED state (i.e., already
> accepted). This is a "success-with-warning" -- the page is usable and no
> action is needed.
> 
> Check only bit 63 (TDX_ERROR) to distinguish real errors from
> success-with-warning returns, rather than treating all non-zero values
> as failures.
> 
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Hmm. Accepting private memory is a security sensitive operation, so I think it
is probably bad to silently hide the detection of re-accepting.

For example, if the kernel accepts a page and sets some values in it, the VMM
could reset the data to zero by re-adding the page and letting the second accept
zero it. It allows the VMM to have some limited ability to mess with guest data.
If we detect a re-accept we should probably warn on it actually.

Not sure on if the specific case in this series is problematic, but this patch
changes the behavior generally.