Re: [RFC PATCH v1 06/11] PCI/TSM: Describe the PCI attestation control family

[Jason Gunthorpe <jgg@nvidia.com>]

On Sat, Oct 31, 2026 at 09:35:26AM +0530, Aneesh Kumar K.V wrote:
> > Would this split work here? It would also allow non-PCI SPDM adapters to
> > share the contract. I understand that multi-slot discovery is deferred,
> > but a slot-zero implementation could still use this family and operation
> > layout.
> 
> The only point that remains unclear to me is the distinction between
> EVIDENCE_ACCEPT and SPDM_AUTHENTICATE. Also, would EVIDENCE_GET retrieve
> fresh evidence on every call? If so, we do not need evidence-refresh.

Lets talk about the desired flow over in this thread:

https://lore.kernel.org/all/20261102172640.GB274202@nvidia.com/

I proposed that LOCK and RUN fit into the normal SPDM flow.

LOCK is effectively starting a SPDM session since it is LOCK that
provides the mechanism to confirm the host hasn't tampered with the
SPDM while we are evaluating it. It has to be tied into the SPDM flow
somehow or it doesn't make sense.

RUN is the natural consequence of finally accepting the SPDM
connection after checking the post handshake signed evidence and maybe
a measurement.

Every SPDM flow should end in some kind of 'RUN' step. It signals to
whatever is waiting that the SPDM session was authenticated by
userspace.

It is a bit unfortunate that the IDE setup was bundled into the
CONNECT, before we have a chance to inspect the evidence, but I don't
think there is an practical downside to that. Though we shouldn't
consider that the right approach.

Jason