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

[Kiryl Shutsemau <kas@kernel.org>]

On Wed, Sep 16, 2026 at 06:16:30PM +0000, Edgecombe, Rick P wrote:
> Kiryl, 
> 
> On Mon, 2026-09-14 at 20:37 +0200, Ard Biesheuvel wrote:
> > This is a follow-up to [0].
> > 
> > Move arch_accept_memory(), which is only called by the EFI stub and
> > never by the decompressor on a non-EFI boot, into the EFI stub, and
> > avoid relying directly on decompressor APIs such as error().
> > 
> > Instead, call tdx_panic() on a failure to accept memory in a TDX guest.
> 
> The TDG accept call can return:
> 
> TDX_OPERAND_INVALID - That would be a bug in Linux TDX code, we don't need to
> pass it to the caller. Probably don't need to handle it.
> TDX_PAGE_ALREADY_ACCEPTED - Potential security sensitive error that is the
> guests fault.

Yes, but it can also be safe in some contexts as we discussed before.

> TDX_PAGE_SIZE_MISMATCH - Already handled. Sort of. Not sure if it is robust to
> S-EPT page size changes?
> TDX_SUCCESS - Already handled
> TDX_OPERAND_BUSY - Can happen from transient host side S-EPT locking. Or it
> could be the guest's fault if they are accepting the same page from different
> vCPUs at the same time, so the guest case is similar to
> TDX_PAGE_ALREADY_ACCEPTED.
> 
> 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?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov