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

[Peter Fang]

On Wed, Jul 08, 2026 at 01:47:29PM -0700, Dave Hansen wrote:
> 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.

I'll just add that this design decision comes from the fact that we're
looking at different kinds of future attestation stuff. Some of it is
quite complex (like post-quantum crypto). Some of it may even require
more complicated interactions with the S3M. Hiding these details allows
all this crypto stuff to look like just another TDX module release. The
host kernel shouldn't be burdened with attestation intricacies, and the
TDX module should just make sure the new module "works".

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

This is pretty spot on based on my understanding. Thanks Dave :)