RE: [PATCH v8 12/15] iommufd/viommu: Allow PCI TSM backends to provide vIOMMU operations

[Tian, Kevin]

> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx>
> Sent: Thursday, November 5, 2026 12:16 AM
> 
> In confidential-computing configurations, a vIOMMU may be implemented by
> a TEE Security Manager rather than by the physical IOMMU driver. Such an

TSM is the firmware. Here it is the TSM driver.

> implementation also needs the TSM identity when creating and validating
> vdevices.
> 
> Allow VIOMMU_ALLOC to first query the TSM associated with the target PCI
> device for vIOMMU operations. Fall back to the physical IOMMU driver
> when the TSM does not provide operations for the requested vIOMMU type.
> 
> Resolve the PCI TSM association under pci_tsm_rwsem, pin the module
> providing the operations, and take a TSM device reference. Store the TSM
> device in the vIOMMU and release both references on allocation failure,

what does "both references" mean?

> fallback to the physical IOMMU driver, or vIOMMU destruction. Keep the
> module pinned until after dropping the device reference, since the final
> put may release the TSM device.
> 
> The device reference preserves the TSM allocation. Backends providing
> vIOMMU operations must not unregister their TSM while the module is pinned,
> since the reference does not prevent backend resource teardown.
> 
> This enables the Realm vIOMMU implementation to provide its operations
> through the PCI TSM backend and retain the TSM identity needed by its
> vdevices.

It's not specific to Realm vIOMMU, and Realm is never explained in
prior patches.

> @@ -49,15 +52,33 @@ int iommufd_viommu_alloc_ioctl(struct
> iommufd_ucmd *ucmd)
>  		rc = -EOPNOTSUPP;
>  		goto out_put_idev;
>  	}
> -	if (!iommu_dev->ops->get_viommu_ops) {
> -		rc = -EOPNOTSUPP;
> +	tsm_dev = tsm_get_device(idev->dev);
> +	if (IS_ERR(tsm_dev)) {
> +		rc = PTR_ERR(tsm_dev);
> +		tsm_dev = NULL;
>  		goto out_put_idev;
>  	}

Is it legal to have a device connected in tsm (i.e. with a valid
pdev->tsm) but one wants to assign it to a non-confidential
guest using a non-cc vIOMMU type?

If yes we want to fallback to the physical IOMMU driver even
when tsm_get_device() returns an error.