Re: TDG quote analysis

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

On Fri, 2026-09-18 at 06:13 -0700, Sean Christopherson wrote:
> On Fri, Sep 18, 2026, Rick P Edgecombe wrote:
> > On Thu, 2026-09-17 at 17:04 -0700, Sean Christopherson wrote:
> > >   If supported for the specific request type, the host VMM can request an
> > >   interrupted request to be aborted.
> > > 
> > > Though per the above, apparently whether or not that's going to be
> > > supported is
> > > TBD?
> > 
> > So extension aborts are a whole 'nother topic. And "support" has a nuanced
> > answer to boot. I'd be very glad to hear your thoughts on it. Should we
> > leave it for a later topic or get into it now? I *think* we don't need it,
> > but the more we get into the details here, the more it's a notable thing we
> > haven't covered.
> 
> How is saying "I no longer want to complete this quote" at all complex?  I can
> see how aborting a request to the S3M might be somewhat pointless, but
> inserting the equivalent to signal_pending() in a long-running operation
> doesn't seem that difficult.

As an interface it is not complex. But as an implementation, there are tradeoffs
and various options.
> > > 
> > > [...]

> > > 
> > 
> > I think the abstract descriptions are not helping, so I'll try some more
> > details. Today the "thread" involves something like a vCPU in a TD. You can
> > see
> > some references in the TDX base spec like:
> >    Currently, TDX Module extensions are implemented as guests running in
> > SEAM non- root mode, called NRX Modules. Technically, each NRX Module is
> > similar to a TD.
> 
> So my above statement that "it's not true interruption, it's basically
> voluntary preemption" is wrong?  Because if the quote crud is running in a TD,
> then events will trigger VM-Exit, and it will be impossible to make forward
> progress without SEAMRETing to the host.
> 
> If that's true, then that changes my understanding of this just a bit, because
> it means the quote operation isn't manually saving state at a "good stopping
> point", it's relying on the VM-Exit to save/restore at whenever it happened to
> be.

Yea, I'd think it is best not to mess with crypto implementations to add
anything like checkpoints. That is what extensions bring to the table. The other
resumable seamcalls basically work like checkpoints. But it is not suitable for
all operations.

>  But given that you say "This idea came up before actually", maybe chunking
> the quote operation isn't a big lift?

The idea that came up was to have a saved state are per-TD. But this only
eliminated concurrency issues in the SW based flow. In the future a HW based
flow would be S3M limited. Which is why I keep saying a redesigned solution
should be robust to concurrency limitations.

> 
> But the original mail says this:
> 
>    -- Guest Interrupts --
> 
>    It is not nice to keep the guest from running for too long. The
> TDH.QUOTE.GET
>    SEAMCALL monitors for host interrupts, but not guest ones. Similarly, the
> SGX
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    quoting enclave doesn't know what is happening in the TD. So, to help
> reduce guest latencies, the GHCI exposes a way to register for a notification
>    (SetupEventNotifyInterrupt) when the quoting is finished. A quote TDVMCALL
>    handler can start the quote operation on another host thread, and resume
>    guest execution waiting for the quote to finish.
> 
> which strongly suggests active polling.  Do you see why I don't want abstract
> descriptions?  Similar to changelogs, there's a balance between "too detailed"
> and "too abstract", and right now all of this is firmly on the "too abstract"
> side of the world.
> 

For a host interrupt, I expected basically the same flow as a normal TD. For the
guest flow, I don't know the exact vmx-level solution for it. I threw out
polling and heard there could be a cleaner option. Not sure what it was.

> > 
> > 
> > Dave will probably not get a chance to respond this week, but we should
> > maybe discuss what acceptable guest latency actually is.
> 
> Yes.  But it's not necessarily about "acceptable" guest latency, I care more
> about *predictable* guest latency.  E.g. making up numbers to illustrate the
> point, achieving 50us latency for the happy case is meaningless if the P99
> latency is 10ms.

The SEAMCALLs today have max latency and they get measured through some testing
process. In practice, some exceed it based on the reasoning that they are only
run once or a few times (setup, etc). So for the host side that is how it got
discussed. It was in terms of worst case.

But now I'm wondering what your specific interest is. It seems you have more
interest in non-KVM in-the-loop guest side latency than you did on host side.
Which is fine. But it makes me want to double check: You want an average and
worse case latency for the first DICE attestation "SW" flow?

Or you want an average and worst case promise for the future flows?

Or you want an average and worse case based on whatever guest interrupt
detection scheme is used for TDG extension calls?

The last one seems the most relevant to me. And the point would be to determine
the tradeoffs between host thread based quote call and a TDG call. But of course
none of this is built yet such that it could be measured. This was the "here is
how it could look in general" discussion. So I think it would take some TDX
module POC work.