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 <aneesh.kumar@xxxxxxxxxx>
> Sent: Friday, September 25, 2026 4:30 PM
> 
> "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.

iommu_ops is provided by the IOMMU driver, which implies the
related knowledge is kept in the IOMMU driver.

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

will do. Hopefully they are all about the TSM driver calling some
IOMMU driver helpers, then would be less a concern to abstract.

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

I originally considered to have the TSM driver register callbacks to
the IOMMU driver. No change to IOMMUFD. But Jason's idea on
connecting it directly via tsm_ops is cleaner.