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

[Dan Williams (nvidia)]

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

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.