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

On Wed, 2026-08-12 at 16:10 -0700, Sean Christopherson wrote:
> > Yea that was my suspicion. I'm not sure if separating them was really Sean's
> > understanding or not. 
> 
> LOL, most definitely not.  Though I have a naive question at this point: why
> can't the TDX-Module extract the bits from the report and put them in the
> right places when generating the quote?

It totally can. If we do the platform scoped quote operation option, then we
grow the report to include all the TD details. Then the quote operation would
extract them from the TDX specific report and put them in their DICE quote
location. It doesn't need to have its own access to the TD details. They come in
the report.

This is what drives the fallout of growing the report in that option. And I
guess defining some new report formats to hold the new stuff. But that is TDX's
job to manage.

> 
> > But the other part is that the verifiers and other VMM infrastructures are
> > already expecting this standard format. It would have a lot of downsides.
> > 
> > But the "grow the report" or "grow the report and quote" are still options
> > that leave the quote in the expected DICE format, right? Sean I'll assume
> > you still prefer the "grow both" option for the sake of kicking the quoting
> > responsibilities out of KVM.
> 
> Not necessarily.  If doing the right thing from a "what's intended and sane"
> perspective is to put some quoting responsibilities on KVM, then so be it. 

I think the only pure answer is go back in time and delete the SGX based
attestation. Between the two options here I give "TD scoped quote" the narrow
win. If you add in that we (Intel Linux TDX folks here) don't need to go push
for changes to the module, then it's a clear win. But even without that, still a
narrow win I think.

> But I would like to have a passing understanding of what all is going on, if
> only so that I can justify why the new uAPI is being added when I send Paolo a
> pull request.  I'm pushing back purely because I quite literally don't
> understand why KVM needs to be involved.

Totally makes sense. And I only entertained the wild "split them" idea because I
don't see any harm in enumerating *all* the options. I have faith we will come
to some reasonable decision.

Hmm, let me flag Artem to see if he can add anymore weight one way or the other
from the migration POV.