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

[Kiryl Shutsemau]

On Wed, Sep 23, 2026 at 04:34:47PM +0200, Ard Biesheuvel wrote:
> 
> 
> On Fri, 18 Sep 2026, at 12:45, Kiryl Shutsemau wrote:
> > 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.
> >
> 
> Is there any way we could make some progress here?
> 
> Ultimately, the thing I am after is to get rid of the call from the
> decompressor to EFI stub's snprintf(), which I want to remove. For
> the time being, I am more than happy leaving the memory acceptance where
> it is, and just dropping the call to snprintf().

Please go ahead with the move. Rick's questions are about what
tdx_accept_memory() should return, not about where the caller lives,
and can be sorted out separately.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov