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

[Kiryl Shutsemau <kas@kernel.org>]

On Fri, Sep 18, 2026 at 01:28:56PM +0800, Yan Zhao wrote:
> 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?

Right, for accept_memory().

The lock itself is dropped around the TDCALL, but the range stays on
accepting_list until the bits are cleared, and the overlap check is done
in unit_size granularity, so a second caller for the same unit spins
until the first one is done and then finds the bits clear. Both (a) and
(b) are covered there.

There is a second ACCEPT issuer that does not look at the bitmap at
all: shared->private conversion in tdx_enc_status_changed().

It does not need the bitmap because the memory came from the page
allocator or memblock and got accepted before it was handed out. It also
has no per-range serialization; mem_enc_lock is only taken for read. So
ALREADY_ACCEPTED on that path means either the guest converted the same
range twice (a double-free class of bug) or the VMM acked MapGPA(shared)
but never removed the private page. Either way the page there is the one
the guest accepted earlier, and the failure already comes back as -EIO
rather than a panic.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov