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

[Edgecombe, Rick P]

+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?


Here is a strawman proposal. Please consider critically.

TDX_PAGE_ALREADY_ACCEPTED: Zero memory that was re-accepted and treat it as a
success.

TDX_OPERAND_BUSY host contention: Loop and blame the host for any infinite
loops. It can be not unlike if the host zap's the EPT and the guest gets stuck
on infinite EPT violations. Except that the host does not get any notification
of the trouble it is causing... Some sort of TDX arch change to notify the host
of heavy guest-host contention could be worked on in the background?

TDX_OPERAND_BUSY guest contention: RW lock around accept. Normally take the lock
for read, and a single fallback attempt takes the lock for write.

Then I think all errors accept() would want to return to the callers are
handled.

The only thing I'm not sure about is TDX_PAGE_ALREADY_ACCEPTED. Some callers may
want a warning on that case. I think a warning is more in line with what we have
done in similar situations, rather than panic. But a warming would throw off the
EFI stub callers apparently.