Re: [PATCH v2 16/17] KVM: TDX: Add in-kernel Quote generation

[Sean Christopherson]

On Tue, Jun 30, 2026, Dan Williams (nvidia) wrote:
> Edgecombe, Rick P wrote:
> > On Mon, 2026-06-29 at 17:42 -0700, Sean Christopherson wrote:
> > > Answering my own question (though probably poorly), IIUC the answer is that
> > > DICE-based quoting is done through the TDX Module, whereas existing quoting is
> > > done through an SGX enclave and so was routed through userspace.
> > > 
> > > If that's all there is too this, then why is KVM involved?  I.e. why doesn't the
> > > TDX Module provide the quote directly to the guest?
> > 
> > That is a good question. The answer is partly historical reasons, but I think
> > the pros/cons don’t really move the needle too much.
> > 
> > The main benefit of doing it with the host in the loop is that the guest side
> > TDVMCALL quoting interface can stay the same. There is also a wrinkle in that
> > there is a limited HW resource involved in the quoting,

What is this magical resource?

> > so we want to do these operations one at a time. Having a mutex on the host
> > is the KISS way of accomplishing some level of fairness for DOS prevention.

At the risk of unintentionally causing effecitvely DoS by introducing a system-
wide lock.

> > We should've explained this more, but TBH this solution is *way* simpler than
> > the initial one that never saw the light of day. So this extra host work seemed
> > quite small compared to what we have been staring at and we kinda overlooked it.

Simpler for what?

> > The other relevant tidbit is that the TDX module folks have some problems to
> > solve before they can support TDG calls to TDX module extensions. I think we can
> > get them to though. The question is probably really: do we want the guest
> > trying/selecting multiple interfaces, or the host.
> 
> tl;dr: FWIW, host, if only because this is one of many blob transports
> across multiple archs that need host coordination.
> 
> While TDG calls to do the same helps a TDX problem it does not generally
> reduce the Linux problem of multiple archs having multiple blob protocols
> to shuffle data from host to guest in shared memory.

Why is that KVM's problem?

> The current direction for other archs (CCA, SEV-SNP) and blobs (e.g. PCI
> attestation collateral) is shift the burden from arch/*/kvm/ to
> drivers/. There might be a later opportunity to consolidate some of
> those drivers' internals on a cross-arch generic transport (AF_VSOCK),
> but there remains a requirement to talk to the host.

Why?

Bluntly, this series is unreviewable.  I've speed read through most of the patches,
and I have *zero* clue as to *why* any of the design decisions were made.  E.g.
why is there a common buffer that's apparently shared by all CPUs and VMs, only
for the API to immediately allocate per-quote memory and copy out the buffer?

The changelogs are all heavy on the "what", but explanations of why any of this
is being done, and in the exact way it's being done, are non-existent.

So, back up to the beginning and explain why I should spend any time deciphering
this series, because as-is I don't have the interest or the time.