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

[Edgecombe, Rick P]

On Wed, 2026-07-01 at 10:25 -0700, Sean Christopherson wrote:
> > > 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?

It's a HW crypto thing. I'll let Peter explain more.

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

The DoS that people are interested in trying to prevent is a TD getting starved
of quotes forever. So the lock is supposed to give some eventual fairness.
Eventually the guest gets its quote even if it has to wait.

If instead contention throws a BUSY code to the guest, the guest spins trying.
That wouldn't have the guarantees.

So I think the two options are: have some lock in the TDX module, or have a lock
of some sort in the host. I think actually a waiting lock in the TDX module is
possible. But I think there are tradeoffs besides where the extra code is. If
it's in Linux we get a lot more control, lockdep, etc.

BTW the "historical reasons" part I mentioned involves a past effort to create
configurable host controlled policies around managing these resources. So part
of the simplification is doing a simple eventually fair global lock instead of
something more complicated.

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

Linux of course.

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

I'm slightly lost on this too, so will leave it to Dan.

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

We can keep discussing it, but...

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

...it sounds like it would be better if we tried again with a proper
explanation, rather than try to back out of where the current presentation left
you?

This should be a pretty simple feature. But there is a higher level theme of
what is responsible for locks and scheduling in the overall TDX solution. This
spills into a lot of future stuff. We can try to find the right level.