Re: TDG quote analysis

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

On Wed, 2026-09-16 at 16:57 -0700, Sean Christopherson wrote:
> > The current estimate is 10s of milliseconds for HW based, and
> > milliseconds or less for CPU based.
> 
> I am beyond confused.

Sorry if this is another gap. Trying to find the right level to cover the
important points. Did we not talk about S3M? 

>   What is "HW based" versus "CPU based"?

"HW" is talking about the S3M thing. The quote operation could go directly to
the S3M to get the quote. (HW based) Or it could get an intermediate key and
generate quotes using CPU instructions. (SW based). Think like a crypto library
in the TDX module.

> 
> At this point, I don't care about the gory details, I just want to understand
> the basics:
> 
>  - Does generating a quote require the CPU to actively execute instructions?
>  - If not, how does software know when a quote is ready? 

Oh man. There are actually a ton of attestation plans. I don't know which will
become real. So these two behaviors we are enumerating are actually an editorial
decision.

The software based flow would be expected to first. It would involve the CPU
doing crypto stuff as above. 

Then a HW based flow where the crypto happens on the limited HW resource. This
is where full parallelization is not possible, because the CPU is not doing the
heavy work. You might want this one instead for security reasons. But the main
point of discussing it is that you could expect some quotes to take a long time
and support a limited number of parallel quotes.

But neither of these solutions are actually nailed down yet. How should a off-
cpu based flow work? We can discuss it. I'd think to have some interface that
doesn't require guest changes all the time. Focusing on something that just
supports long quotes seems the most robust.

> 
> I tried peeking at TDX Module source code, but I can't find anything relevant
> even in the latest TDX 2.0 drop.

I have not seen it, don't think Peter either. The posted DICE seamcall quote
code was actually tested on a mocked TDX module. So DICE is early enabling kind
of stages.

It is not the usual years old TDX feature. This is new stuff. Still open and
unfinished, etc. In some ways it's a more complex problem then "cram this TDX
interface into KVM as best you can".