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

[Jason Gunthorpe]

On Tue, Sep 01, 2026 at 06:14:19PM +0530, Aneesh Kumar K.V wrote:
> > 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.

Okay, that's a good reason, but the whole thing just doesn't seem
split right. There is code in arm-cca-guest and code in the viommu
that are all working on the same thing. I don't think it makes logical
sense split like this.

The viommu should be creating the vdev at the logical point in its
flow, when the it creates its vdevice. It shouldn't be disjoint and
separated.

> > 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.

You end up with *two* "vdev creation" operations, one through the new
bind iommufd call and another through the actual vdevice create
iommufd call, and they go do different modules. That seems like a
messy flow.

If we are commited to a viommu then lets use the viommu for everything
and have less code in arm-cca-guest. Get rid of bind as a tsm
operation. Have the smmu driver do it when it creates the vdevice.

You can't call RMI_VDEV_CREATE outside the viommu anyhow as the
vdev_id comes from the iommufd vdevice object's vsid.

This is probably going to work better long term anyhow as we can
construct the vsmmu with exactly the same API surface, and a non-vsmmu
case is really just some special variation of the viommu object that
doesn't create do a RMI_VSMMU_CREATE.

Also, is it really OK to setup the psmmu after creating the pdev? RMM
spec explicitly says that order is allowed? It is a litle bit counter
intuitive.

Jason