Re: [RFC PATCH v4 00/16] coco/TSM: Implement host-side support for Arm CCA TDISP setup

[Aneesh Kumar K . V]

Jason Gunthorpe <jgg@xxxxxxxxxx> writes:

> On Mon, Apr 27, 2026 at 02:23:28PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> 
>> This patch series implements the host-side changes needed for end-to-end
>> Arm CCA TDISP setup. It adds the RMI/RHI plumbing required to create and
>> manage Realm vdev objects, service device-attestation object requests, and
>> complete the KVM/RMM flows needed for device run-time transitions.
>
> So this is enough for the realm to see a physical PCI device inside it
> without any vSMMU inside the realm?
>

There are multiple series, and this is the final one:

1. arm-cca-guest series
2. arm-cca-host IDE setup series
3. iommufd interface for TSM operations
4. arm-cca-host TDISP support (this series)

>
> It is really weird to see a viommu for a case where there is no
> viommu..
>

We ended up with a viommu despite having no stage-1 SMMU or vSMMU
because it held the KVM reference needed by item (3) above [1]. With the
recent changes in that series [2], we now inherit the KVM details from
VFIO through iommufd_device_bind. I can possibly look at using the idev
for this instead.

[1] https://lore.kernel.org/all/20260309111704.2330479-2-aneesh.kumar@xxxxxxxxxx
[2] https://lore.kernel.org/all/20260525154816.1029642-1-aneesh.kumar@xxxxxxxxxx


> It doesn't do anything except manage memory for the RMM..
>
> It feels wrong that the arm-cca-guest module is calling
> RMI_PDEV_CREATE and RMI_VDEV_CREATE while the viommu is allocating STE
> memory for the PDEV. That doesn't make alot of sense? The STE is
> needed before VDEV_CREATE, right? So why not place it there in the
> flow?
>
> If that's changed then the only thing the viommu does is manage the
> PSMMU, which again, seems like something VDEV_CREATE needs, so why is
> a viommu involved at all?
>

We do not have a separate vdev-create operation; instead, we have
tsm_bind. The required iommufd objects (idev/viommu) are set up before
tsm_bind.

Currently, the primary reason for having a viommu is to obtain the KVM
reference. Now that the KVM details are inherited from VFIO through
iommufd_device_bind(), I can look at using the idev instead and dropping
the viommu requirement.

>
> The smmu driver involvment would be much smaller if it was only the
> interrupt routing and some helper to return the psmmu addr for a
> struct device that the arm-cc-guest module can call to manage the
> psmmu?
>

I designed this so that the PSMMU details are managed by the arm-smmu
driver, with minimal involvement from arm-cca-host. If the arm-smmu
driver does not set up the PSMMU correctly, tsm_bind, which is handled
by arm-cca-host, can fail.


> But I'm also sitting here scratching my head a bit, did the tsm_ops
> design go the wrong way? Should we have run more of that through a
> viommu instead of tsm_ops? Bind is sort of an illogical operation
> without a viommu, even if it is a nop viommu.
>
> I suppose it depends what it looks like when a real vsmmu is
> created.. That probably needs a special viommu object, and do we get
> into order problems if the lifecylce becomes split to tsm and viommu?
>
>> RHI v1.0 BET1 specification [5].
>> 
>> At a high level, the series adds support for:
>> - host-side vdev communication and lifecycle management
>> - host handling of RHI DA object read/size requests
>> - host-side fetching and caching of interface reports and measurements
>> - KVM handling of vdev request/complete exits
>> - KVM handling of map/validation exits and teardown on granule destroy
>> - vdev transition to TDISP RUN state
>> - enabling DA in Realm create parameters
>> 
>> The series builds upon the TSM framework patches posted at [2] and depends on
>> the KVM CCA patchset [3]. A git repository containing all related changes is
>> available at [4]. kvmtool repo is at [6]
>
> It looks like it also needs the series that adds bind to iommufd too
>
> Jason

-aneesh