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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Nov 13, 2026 at 09:59:56PM +0530, Aneesh Kumar K.V wrote:

> >> BTW, this proposal does require RMM changes. I have also omitted SPDM
> >> 1.3 multi-key support from this diagram because it will be easier to
> >> follow once the SPDM 1.2 flow is clear.
> >
> > IMHO, leave everything alone as is today. We can make it work well
> > enough as is.
> 
> Could you describe the flow you have in mind? Would we restrict
> everything to slot 0, without allowing userspace to select another slot,
> as this patch series does?

Unchanged from the earlier email, option a

https://lore.kernel.org/all/20261103151643.GI274202@nvidia.com/

1) CTLV Start Connect -> NOP
2) CTLV Try to fetch certificates -> EOPNOTSUPP
3) CTLV Finish Connect w/ slot #:
    PDEV_CREATE
    COMMUNICATE
    PDEV_NEEDS_KEY
    COMMUNICATE
    PDEV_READY
4) CTLV Now can fetch limited transcript and cert chain:
    RMI_DEV_PROTOCOL_DATA is broken up into 6 transcript entries "VCA"
    Certificates for slot # are directly from the RMI_DEV_IDENTITY
    (hopefully, the specs are unclear *exactly* which bytes are
     captured)
5) CTLV Accept
    RMI_PDEV_STREAM_CONNECT

Then VMM creates a special "vdevice attestation FD" through iommufd.
RHI maps onto this:

a. RMI_DEV_PROTOCOL_DATA reconstruct by concatenating the 6 transcript
   messages to make VCA
b. RMI_DEV_IDENTITY reconstruct by reading the certificate chain
c. RHI_DA_VDEV_GET_MEASUREMENTS and RHI_DA_VDEV_GET_INTERFACE_REPORT
   map to the evidence collection API

The kernel knows that the "vdevice attestation FD" uses the _VDEV_
versions of the RMI APIs while the /dev/attestationXX FD uses the
_PDEV_ versions.

From there we might someday have common code to do capture and then we
drop the VCA decoding and RMI_DEV_IDENTITY to just use the capture
logic. This now gives a complete transcript.

Then the other emails enable option c which makes the certificates
available at step #2.

I've got similar mappings drafted out for the other two arches and
this seems to be OK.

Jason