Re: [🚨ext] Re: [PATCH v3 0/2] virt: tdx-guest: Fix and speed up the wait for a Quote

[Moe Mahhouk]

On Mon, 2026-11-02 at 19:55 +0000, Edgecombe, Rick P wrote:
> Long term though, isn't this a better option? This patch is
> essentially a performance optimization.

Agreed that interrupt-driven completion is the better end state where the
VMM supports it. But I don't think it can replace polling.
SetupEventNotifyInterrupt is optional in the GHCI and enumerated through
GetTdVmCallInfo. KVM only forwards it to userspace (since v6.16), and a
VMM that doesn't implement it returns SUBFUNC_UNSUPPORTED. So the guest
still needs a polling fallback for older KVM/QEMU and for other VMMs.
Patch 2 is about that fallback.

> Polling is always going to be weird. And when the attestation speed
> changes (possible in the many upcoming attestation plans) this tuning
> could again be suboptimal.

The fixed one-second interval is the tuning that ages badly. It puts a
one-second floor on each Quote and, with quote_lock, caps a TD at about
one Quote per second. The backoff assumes no speed: a fast Quote is
seen within a tick or two, and a slow one at most 100 ms after it
completes, with at most ten wakeups per second.

Polling was originally chosen (f4738f56d1dc) because Quote generation
was "not time-critical or frequently used". That no longer holds for
users that bind a fresh Quote to every connection, such as attested TLS.

I'm happy to work on event-notify support as a follow-up: use it when
GetTdVmCallInfo reports it, and keep the backoff as the fallback. Would
you take patch 1 now (a standalone fix, Cc: stable) and patch 2 as the
fallback improvement? Or would you rather see patch 2 together with the
event-notify series?