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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Sat, 2026-08-15 at 14:39 +0300, Artem Bityutskiy wrote:
> On Fri, 2026-08-14 at 15:55 +0000, Edgecombe, Rick P wrote:
> > On Fri, 2026-08-14 at 08:45 +0300, Artem Bityutskiy wrote:
> > > But why DICE-based attestation uses 2-flow design? Could TD run a
> > > TDCALL[TDG.GET.QUOTE2] or something directly. No concept of TD report
> > > would be needed. That would be my current vision of "cleanest".
> > 
> > We discussed this approach internally and in PUCK. The problem is there is a
> > shared resource, and so something needs to handle locking and fairness
> > between
> > the guests. Going to the host keeps all the scheduling type stuff in that
> > domain.
> 
> Good point. I did not think about this aspect.
> 
> 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.

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.

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.

So yea, I wonder too if we could make this a general pattern.