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

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Friday, September 25, 2026 3:21 AM
> 
> On Thu, Sep 24, 2026 at 07:48:08AM +0000, Tian, Kevin wrote:
> > > 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 main purpose and point would be to keep the TSM code in TSM and
> out of iommu drivers.
> 
> And we don't want a module dependency from iommu -> tsm either..

Yes, but the reverse should be OK (as you also replied to patch6).

> 
> > The underlying IOMMU driver still needs to understand this vIOMMU type
> > to check vendor-specific compatibility and provide the relevant hardware
> > parameters.
> 
> It shouldn't, if the user requestes a TSM iommu type that should go
> directly to the TSM driver, and the TSM driver should involve its
> physical iommu as necessary.

I was talking about what this abstraction provides. The validate/
get_param() callbacks implies that the related knowledge is kept
in the iommu driver, but I agree that they should be put in the TSM
driver directly.

> 
> > There may also be further vendor-specific interactions between
> > the IOMMU and TSM drivers.
> 
> This is the big question - how big is the entanglement. ARM's is
> small. What is Intel like?
> 
> If Intel and ARM are small, and they should be because the T=1 VIOMMU
> is entirely handled by TDX/RMM for security, then I feel this is the
> right way for them. It keeps the code nicely isolated with only a tiny
> bridge.

there are more interactions in the TDX side, but all from the TSM
driver to the IOMMU driver from what I checked now, e.g. about
DID reservation at the initialization phase. 

Looks there are some resource shared between the untrust and
trust invalidation paths, as iommu->qi->q_lock is also acquired
in the trust path. I still need to understand the motivation behind,
but this can be resolved properly by exporting a helper to the
TSM driver even if it's truly required.

There may be more... I'll try to figure them out. Likely there
wouldn't be a requirement leading to the dependency from IOMMU
to TSM.

> 
> AMD is probably not like that.
> 
> > 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.
> 
> Glancing through these patches I think the abstraction may be too big,
> really the point is to allow TSM to create a viommu, I'm a little
> confused why there is so much stuff here.

that's my feeling too.