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

["Ard Biesheuvel" <ardb@kernel.org>]

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().