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

[Aneesh Kumar K . V]

"Tian, Kevin" <kevin.tian@xxxxxxxxx> writes:

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

Will use TSM driver instead of TSM 

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

device reference and module reference. How about i update this to

Resolve the PCI TSM association under pci_tsm_rwsem, take a TSM device
reference, and pin the module providing the operations. Store the TSM
device in the vIOMMU. Release the device reference and module pin on
allocation failure, fallback to the physical IOMMU driver, or vIOMMU
destruction. Drop the device reference before releasing the module pin,
since the final put may call into the backend module.



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

I will drop this para.

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


tsm_get_device() does not use the vIOMMU type, so an error return
(rather than NULL) indicates an actual error. In the case you describe,
tsm_get_device() should return NULL or a valid TSM device. For a valid
TSM device, tsm_viommu_get_ops() will return NULL because the TSM driver
does not support the non-confidential vIOMMU type, allowing fallback to
the physical IOMMU driver.

-aneesh