Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Jason Gunthorpe <jgg@nvidia.com> writes:

> On Fri, Nov 06, 2026 at 08:53:39AM -0700, Dave Jiang wrote:
>> 
>> 
>> On 11/4/26 9:54 AM, Dave Jiang wrote:
>> > 
>> > 
>> > On 11/4/26 6:41 AM, Jason Gunthorpe wrote:

 [ ... 13 lines skipped ... ] 

>> I generated a diagram that hopefully better reflects Option A with TDX better than the current public documentations:
>> 
>> Option (a) on TDX, with the current TDX Connect ABI: slot 0 only, no TDX
>> change. Numbers in the left margin point to the notes below.
>> 
>>   ---->   call                 <- - -   return
>>   <---->  SPDM request and response in clear text, relayed by the host
>>   <====>  the same, inside the SPDM session
>
> It looks OK, thanks.
>
> I have a few thoughts
>
> 1) I would very much like it if the core SPDM code in the kernel
>    can snoop the DOE messages from the TSM. If we do this then the
>    kernel can directly capture the full transcript:
>
>> (4)  |                    |                       | GET_VERSION            |
>>      |                    |                       |<---------------------->|
>>      |                    |                       | GET_CAPABILITIES       |
>>      |                    |                       |<---------------------->|
>>      |                    |                       | NEGOTIATE_ALGORITHMS   |
>>      |                    |                       |<---------------------->|
>>      |                    |                       | GET_CERTIFICATE slot 0 |
>>      |                    |                       |<---------------------->|
>> (5)  |                    |                       | KEY_EXCHANGE slot 0    |
>
> With perfect consistency on all vendors.
>
> Further, it will also be able to capture the GET_CERTIFICATE during
> the preamble so again we get greater consistency for everyone.
>
> I'm very interested in this because it frees the uABI from any
> variation in choices the TSM may have made. I have the full perfect
> transcript in the kernel and I will ALWAYS present the same uABI to
> userspace regardless what the TSM offers.
>
> Like a whole bunch of TSM FW API just to do this:

Can you help me understand why we need to snoop the DOE messages? IIUC,
the earlier proposal for 1.2 was to use Rust SPDM to perform the
following:

GET_VERSION
GET_CAPABILITIES
NEGOTIATE_ALGORITHMS
GET_DIGESTS
GET_CERTIFICATE for all slots in the slot_mask returned by GET_DIGESTS
CHALLENGE using the slot 0 key (At this point, we can also verify that
we received the certificates for all slots supported by the device.)

The host then select a slot and use it to establish the IDE connection?
(For intel we can only select slot 0 here?)

What does snooping provide in this context?

-aneesh