Re: [PATCH 0/3] Move memory acceptance x86 arch code into EFI stub

[Yan Zhao]

On Fri, Sep 18, 2026 at 02:29:55AM +0800, Edgecombe, Rick P wrote:
> +Yan 
> 
> On Thu, 2026-09-17 at 14:32 +0100, Kiryl Shutsemau wrote:
> > > I guess the caller could care about TDX_PAGE_ALREADY_ACCEPTED errors. But
> > > SNP
> > > doesn't do anything for this case. It seems like part of the problem is that
> > > we
> > > are passing errors back that the caller can't feasibly handle.
> > 
> > Maybe. I don't understand SNP model and why they don't care about errors
> > here.
> > 
> > Do you have a proposal here?
> 
> Yan pointed out that future TDX modules will not take an S-EPT entry lock on
> accepting a NP S-EPT entry. However, I think this won't prevent guest caused
> busys on re-accept attempts?
Re-accept attempts may occur due to:
(a) two concurrent ACCEPT TDCALLs, where the one that arrives slightly later
    returns either TDACCEPT_ALREADY_ACCEPTED or TDX_OPERAND_BUSY.
(b) two successive ACCEPT TDCALLs on the same GPA.

Since Linux guest always invokes ACCEPT TDCALL before a memory access, and
accept_memory() always checks the unaccepted_table->bitmap before invoking the
ACCEPT TDCALL, case (b) should be impossible in practice, right?

Is case (a) a valid scenario, and does it actually occur in a Linux guest?