SPDM implementation over DOE upon FLR

[kartd0122133]

Hi all,

According to the PCIe Base Specification Revision 6.4, it states that "An FLR to a Function during the processing of a CMA-SPDM request must result in that Function terminating its processing of the request, and that Function not returning a response to the request."

However, I am looking for some guidance on how to properly handle the termination of a request in progress.

Below are a few scenarios we are currently considering:

1. When the in-progress request is SET_CERTIFICATE: If the firmware has already written/saved the certificate into the slot before the FLR occurred, how should we terminate the process? Should we perform a rollback to the previous state, or is it acceptable to just let the write operation complete internally (while still withholding the response)?

2. When the next incoming request is a retry of the interrupted request:
   This is the scenario we anticipate happening. However, the interrupted request might have already been pushed into the SPDM message transcript.

• If we treat the incoming request as a brand-new request, I assume the transcript validation will fail.

• If we treat the incoming request as a retry, the firmware would need to track and conclude the previous request's state. What is the standard practice here?

3. When the next incoming request is a completely new request:
   If the firmware is still cleaning up the state of the interrupted request when a new one arrives, how should we handle it? Is it compliant to return an ErrorCode = Busy according to DSP0274 (Section 8.9, Requirements for Responders: "A Responder that is not ready to accept a new request message"), or should the cleanup be synchronous with the FLR?

Any insights or recommendations on how others have implemented this would be greatly appreciated.

Thanks,

[steven-bellock]

Ideally these questions should be addressed by the PCI-SIG Protocol Working Group.