RE: [RFC PATCH v6 00/11] iommufd: Infrastructure for vIOMMU creation for confidential guests and guest TSM requests

[Aneesh Kumar K . V]

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

>> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx>
>> Sent: Thursday, September 17, 2026 10:02 PM
>> 
>> This series adds the IOMMUFD and PCI/TSM infrastructure required for device
>> assignment. It introduces an IOMMUFD-owned vIOMMU provider registry and
>> the
>> IOMMU_VDEVICE_TSM_REQ ioctl.
>> 
>> The series adds a vIOMMU provider abstraction that allows a subsystem
>> other than the physical IOMMU driver to implement a vIOMMU type. It groups
>> the vIOMMU operations with their module owner and private data, and makes
>> that implementation discoverable during vIOMMU allocation.
>> 
>> External providers are selected by exact vIOMMU type. When no provider
>> matches, vIOMMU creation falls back to the physical IOMMU driver. Once a
>> provider matches, its result is authoritative and failures do not trigger
>> fallback.
>> 
>
> I wonder whether this abstraction is necessary.
>
> The underlying IOMMU driver still needs to understand this vIOMMU type
> to check vendor-specific compatibility and provide the relevant hardware
> parameters.
>

There is an iommu_ops callback, viommu_get_params, that can be used to
check compatibility and return hardware parameters.

> There may also be further vendor-specific interactions between
> the IOMMU and TSM drivers.
>

This is an important point. Can you identify those interactions so we
can determine whether an iommu_ops callback is the right abstraction?

> In that case, the abstraction risks becoming
> little more than a connection between two vendor-specific drivers, while
> making it harder to maintain a clear scope for its operations.
>
> Would it be simpler to provide helper APIs and let the IOMMU driver use
> its own interface to delegate vIOMMU operations to the TSM driver? 
>

Does this mean that the vIOMMU would be created by iommufd, with
the TSM driver registering callbacks that iommufd invokes for
TSM-related operations?

> From iommufd's perspective, the vIOMMU type and its operations would
> still be handled by the IOMMU driver.

-aneesh