Re: TDG quote analysis

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

On Wed, 2026-09-16 at 11:00 -0700, Sean Christopherson wrote:
> On Wed, Sep 16, 2026, Rick P Edgecombe wrote:
> > This DICE quote generation can take a long time. Exactly how long is not
> > known, but it is expected to vary and often exceed the time a SEAMCALL can
> > be executing in the TDX module by a considerable amount.
> 
> What's the ballpark?  Are we talking tens of nanoseconds, tens of
> microseconds, tens of milliseconds?

I asked about this too. I have not seen any measurement yet for the real
implementation. AFAIU the PQC stuff is not settled enough at the industry level
to be sure in the long run. I have been under the impression of at least a ms or
2 for PQC signature based on general PQC signature benchmarks I've seen. That is
only my guess though.

If you are thinking the implementation could punt on how to handle the guest
interrupts for now, that seems reasonable. I'd think exiting to handle the host
interrupts could not be skipped though.

> 
> Is the CPU spinning the entire time?  Or is the quote degeneration I/O-like?

Today the CPU will mostly be working. In the future it could be waiting for the
shared HW. This would take much longer.

> > 
>    
> >    A resumable TDG quote call would have to solve a slightly different
> > problem. A bad guest could refuse to resume the TDG call and hold the TDX
> > module extension save state slot hostage.
> 
> The whole "what about guest interrupts?" thing makes me think the quote
> generation is CPU-bound, i.e. not I/O-like.
> 
> Does the TDX Module *need* to provide a save slot?  What would prevent TDX
> from requiring the guest to provide storage for whatever in-flight data is
> needed? That way there it doesn't matter if the guest never resumes the call,
> it can only hurt itself.

I was thinking about this too, but thought it sounded a bit like the NAKed SNP
secure AVIC pattern. At least the TDX module would need to handle getting asked
to zap the guest page that was given to be a saved state slot.

The host would probably need to be involved in unmapping the page from the S-EPT
while in use too, since it would need a TLB flush on each vCPU. Otherwise the
guest could see the intermediate memory of the operation. Or, hmm, I guess the
guest could coordinate entering the TDX module on each vCPU to get a flush. That
would be a new one.

> 
> >    If a quote operation is long enough, the TDG SEAMCALL should probably
> > support
> >    a resumable-like flow from the guest side too, where it also monitors for
> >    pending guest interrupts and returns from the TDG call to let the guest
> >    handle them.
> > 
> >    Then the host wouldn't need a thread and a completion guest notification
> >    mechanism. It basically transfers that complexity to the TDX module.
> 
> 
> >    But it also might transfer some of the control. The TDX module would have
> > to embed some policy on how to decide when to inject guest interrupts. If
> > the host and TDX module had different logic on when to actually re-enter the
> > TD, that could be annoying.
> 
> But the TDX-Module already has some policy, no?  In the sense that it decides
> when to exit to the host because there's an interrupt pending.

Yes for exiting to the host. I was talking about re-entering the guest for a
guest pending event of some sort. Like if KVM decides to re-enter to handle some
event, but TDX module decides, nah we are going to work on the in-progress guest
call for a bit first.

> 
> > == Summary ==
> > 
> > From what we found, I think it doesn't seem overly impossible for the
> > module. But the exact cancellation rules and timeout logic would need to be
> > hashed out a bit more. The simple mutex on the host side does still seem a
> > fair amount simpler than the TDX module's fairness options.
> > 
> > How do we feel about the roles and responsibility shifts? Any other problems
> > to solve?
> 
> What about the whole "TD-specific data in the quote" thing?  If getting a
> quote (or report?) is punted to the host, I'd still like to keep it out of
> KVM.

I checked another option for this: Write the nonce to the TDX module via some
new TDG call, then just ask for a TD scoped quote which fills in everything from
what the TDX module already knows. TD details and nonce. Apparently it could
work.

Then nothing gets passed out of the guest except for request for a quote.  We'd
have to break compatibility with the SGX based quotes though. Is it worth it? Vs
just utilizing the upstream KVM functionality unchanged?