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

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

On Thu, 17 Sep 2026, at 20:29, 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?
>
>
> 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.

The memory acceptance occurs after ExitBootServices(), and so there is little the
EFI stub can do at this point except maybe set a variable with an error message
and reset the system. If that is better than a panic(), this is something we can
consider.

However, I'd like to avoid going off into the weeds here with something that was
intended to simply move some logic from one place to the other. The current code
prints an error to the UART I/O port (rather than the PV console TDX uses when
running in the decompressor) and then loops forever. Is that something we could
retain for this series, and then continue the above discussion in the context of
a separate series based on top of that?