Re: [PATCH v3 0/4] tdx-guest: Make Quote buffer size dynamic

[Artem Bityutskiy <dedekind1@gmail.com>]

On Mon, 2026-08-17 at 17:26 +0000, Edgecombe, Rick P wrote:
> > I am curious if today this is an attestation-only problem or a pattern.
> > I mean this "many TDs compete for a shared TDX capability, VMM needs to
> > be involved to handle fairness".
> > 
> 
> Yea, I think it is a really good question. This is getting off topic now, but...
> 
> There is an existing issue we have with the "host priority" (HP) bit. This is a
> part of the TDX arch that is designed to help with guest host contention. For
> example a TDG call like ACCEPT can take an S-EPT lock that the host wants to
> also take with a TDH call. It is sort of important to have the host be in
> ultimate control. So the way the HP bit works is, if the host meets contention,
> it sets the HP bit. The bit means if the guest tries to take the lock again, it
> is blocked without letting the lock get taken. This gives the host a chance to
> retry and succeed. After the host succeeds in taking the lock, the HP bit is
> cleared. This is like a crude fairness thing.

Thanks. Yes, sounds crude, and it does not look like it covers
fairness across TDs. It only covers the "VMM has priority" part.

> But it all depends on the host retrying. If the host never retries because
> userspace intervenes, then the guest stays locked out. We actually hit this
> condition in the tdx mmu stress selftest. So it is on the to-do list to fix in
> TDX arch.

I see, the VMM not making progress blocks TDs which could make
progress otherwise. Thanks for the info.

TDX specs describe the HP_LOCK_TIMEOUT per-TD property (set by the host
via TDH.MNG.WR), which could be used to somewhat make the symptom
somewhat controllable, may be make pain less painful, but it is not a
cure for the illness.

> Now how this connects to the 1-flow vs 2-flow design... As we have been
> discussing this quote/report stuff, I wondered if we couldn't solve the HP bit
> problems with a similar 2-flow thing. For example a TDG.ACCEPT call could exit
> to the host without taking any locks and providing some kind of token, that a
> paired TDH call could be used to complete the accept (and take the locks). TDH
> calls should not be able to accept guest memory arbitrarily, so there needs to
> be some kind of security validation on the TDH call. But then the host could
> control all the scheduling/priority stuff. The overall solution would be better
> for having this locking balancing stuff done in a single place where there are
> no odd overlaps. But it means we also have extra host code for every TDG call
> that takes a problematic lock. Probably more TDX module complexity too.

Yeah. We have TDG.VP.VMCALL as an "exit to the VMM and let it handle
stuff" capability. 

So essentially you are pointing out that one of the approaches is
turning a problematic

TDCALL[TDG.ABRA.CADABRA]

into a

TDCALL[TDG.VP.VMCALL]<AbraCadabra>.

I guess this approach could be used in few selected cases.

Thanks!