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

[Tian, Kevin]

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