Re: TDG quote analysis

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 16, 2026, Rick P Edgecombe wrote:
> Here is the overdue analysis of what a TDG based TDX quote operation could look
> like, pulled together as writeup somewhat quickly. This was from Sean's request
> originally. The writeup is based on a bunch of gathering by Peter, Elena and I.
> Some TDX interrupt input from Binbin.

Thank you!

> 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?

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

>    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.

To me, this just *screams* for a virtio-like device to provide quotes to the guest,
especially if the slow part of quote generation is I/O-like.  Even if it hogs a CPU,
an asynchronous virtio-like interface would be far easier to support.  E.g. the
userspace device backend spawns a thread (affined to the same set of pCPUs as the
vCPU, i.e. to "tax" the guest instead of requiring dedicated "overhead" CPUs),
and kicks the guest when the quote is ready.

Ahh, that's more or less what SetupEventNotifyInterrupt is.  I guess that's not
the end of the world, so long as the backend for SetupEventNotifyInterrupt is
handled entirely in host userspace.
   
>    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.

>    So instead, a TDG call could work by remotely canceling another TD’s paused
>    operation if that TD didn't call back frequently enough. After a time-limit
>    was reached on an extension save state slot usage, another TD’s TDG call
>    could abort the stalled TD’s operation. There existing designs around doing
>    this cancellation already in the TDX extension arch. It would need to be
>    adapted to the guest side calls and incorporate the extra cancellation work
>    into the time limit math. Some good timeouts would need to be picked.

...

>    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.

> == 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.