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

[Dave Hansen <dave.hansen@intel.com>]

On 7/6/26 10:57, Sean Christopherson wrote:
> What is "the S3M" though?  Is it a separate chip a la AMD's PSP/ASP?  Is it a
> per-package thing? Per-core?
I'll give you my rough software guy mental model of what it is: Each
package has its own S3M. They are microcontrollers which are discrete
from the CPU cores. Each S3M gets some CPU physical address space routed
over to it.

> How is it accessed, and what are the "rules" for for those
> accesses?  What types of latencies are we looking at?

As far as I know, the latency for one round trip to/from S3M is on the
order of a "real" device. It has a physical address and when the OS
wants to talk to it, those addresses are mapped with ioremap(). It's
similar to any modern I/O device control plane. Note, though, that for
TDX, there's no ioremap() because the I/O is hidden in the TDX module.

The real overhead comes because the I/O window is essentially 4 bytes
wide (IIRC) and all the data that comes in and out of it has to be
squeezed through that window. It reminds me of a UART, but with a
slightly more arcane interface.

For TDX, though, the craziness is mostly hidden in the TDX module.

> What else uses the S3M?  Do we have to worry about contending with
> non-TDX usage?
There _are_ different users of S3M. But each of them should get their
own I/O address and S3M firmware has to handle talking to those
different users at the same time. The TDX I/O window is owned
exclusively by the TDX module.

So, while S3M has and long and growing list of jobs, the random software
(like the host kernel) poking at one I/O window doesn't have to know
about the other piece of software (the TDX module) poking at another.

I'm sure I got a detail or two wrong in there, so folks that know this
better: please correct me. But I think that's a halfway-decent 10,000ft
view.