Re: [RFC PATCH v6 05/11] iommu: Add a helper to validate a vIOMMU parent

[Jacob Pan <jacob.pan@linux.microsoft.com>]

Hi Jason,

On Mon, 28 Sep 2026 15:20:22 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Mon, Sep 28, 2026 at 11:08:54AM -0700, Jacob Pan wrote:
> > Hi Jason,
> > 
> > On Mon, 28 Sep 2026 13:17:38 -0300
> > Jason Gunthorpe <jgg@nvidia.com> wrote:
> >   
> > > On Mon, Sep 28, 2026 at 09:09:06PM +0530, Aneesh Kumar K.V wrote:
> > >   
> > > > Does that mean the SMMU driver will return viommu_ops before
> > > > iommu_ops->viommu_init() is called? If so, should viommu_init()
> > > > be moved into viommu_ops?    
> > > 
> > > That's probably the cleanest arrangement, yeah. Then the TSM ops
> > > are just the same 'get_viommu_ops' call under TSM and it is easy
> > > to put in a flag 'must have null hwpt' that goes at the right
> > > point. 
> > This should also work for the parentless hypervisor vIOMMU in my
> > RFC: https://lore.kernel.org/linux-iommu/20260925190742.1575380-1-jacob.pan@linux.microsoft.com/T/#t  
> 
> Yes! That case is very similar, the hypervisor under Linux is a close
> cousin to RMM/TDX.
> 
> > I will give below a try, I currently have below (can be avoided if
> > get_viommu_ops() can simply return NULL for the hypervisor type):  
> 
> The amd_iommufd_get_viommu_ops() must only permit its own type, but
> AMD doesn't have a type right now because they are merging their
> patches bit by bit..
> 
> ARM already returns NULL:
> 
> > > +const struct iommufd_viommu_ops *
> > > +arm_smmu_get_viommu_ops(struct device *dev, enum
> > > iommu_viommu_type viommu_type) {
> > >  	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > >  	struct arm_smmu_device *smmu = master->smmu;
> > >  
> > >  	if (!(smmu->features & ARM_SMMU_FEAT_NESTING))
> > > +		return NULL;  
> 
> Though I wonder why would you check for IOMMU_VIOMMU_TYPE_HYPERVISOR
> in the amd driver?
> 
It is an early capability check. AMD vIOMMUs require a nesting
parent, while IOMMU_VIOMMU_TYPE_HYPERVISOR is parentless. Returning
zero prevents the core from allocating an AMD vIOMMU and calling
viommu_init() with a NULL parent. As you said above, AMD doesn't have a
allowed vIOMMU type yet.

> Maybe hyperv should be a TSM?  Maybe we should also route the
> get_viommu through the the "kvm" fd somehow?
Just to understand this better, are you suggesting to do away with
hv-iommu-root driver in the context of external domain attach, instead
let mshv (hyperv) register as a vIOMMU external provider?