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

[Yan Zhao <yan.y.zhao@intel.com>]

On Fri, Sep 18, 2026 at 10:12:10AM +0800, Yan Zhao wrote:
> 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?
Case (a) should be prevented by the unaccepted_memory_lock in accept_memory(),
right?