> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> 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 may also be further vendor-specific interactions between
the IOMMU and TSM drivers. 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? 

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