Re: [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Sep 07, 2026 at 03:15:25PM +0530, Aneesh Kumar K.V wrote:

> I looked into this, and it becomes fairly complicated. We can move all
> vdev/TDI-related code to arm-smmu-realm-v3.c, but that would result in:

I was going for the opposite, you'd move everything out of arm-smmu-v3
and into the arm-cca-host and obtain the viommu through tsm_ops not
through iommu_ops.

I guess I pointed to that in another email.

The only thing arm-smmu-v3 should provide is a simple function to give
the pdev phys and irq parameters. arm-cca-host calls that when it
creates an viommu object.

> 1. Adding more CCA-specific code to the SMMU driver.
> 2. arm-cca-host continuing to own the TSM link setup (IDE).
> 3. Adding callbacks from the device communication helpers back into
>    arm-cca-host, since device communication still goes through DOE.
> 4. Moving the device communication helpers to firmware/arm-rmm and adding
>    something like:

With the above change you don't need to do any of this.

> The locking also becomes more complex. Unlocking a vdev can trigger a
> stream key refresh, which is owned by arm-cca-host. Currently, the locking
> is simpler, using pci_tsm_rwsem and pci_tsm_pf0::lock. With the SMMU driver
> owning the vdev/TDI, we would have:

You can't really avoid something, the vdev *IS* the TDI and the ops to
effect it come in through the iommufd path. The ideal version is the
tdi is never used outside the iommufd path so you don't need to mesh
the locking quite as carefully.

> - pci_tsm_rwsem protecting the lifetime and registration state of
>   pdev->tsm.
> - pci_tsm::tdi_lock protecting the function's pci_tdi pointer.

Like here, why is there a pci_tdi linked to pci_tsm? Anything coming
in outside the iommufd locking is very suspect.

And the iommufd locking should spill over to the TSM, you should not
be able to remove a tsm while a viommu object exists.

Jason