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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Sep 28, 2026 at 03:24:02PM -0700, Jacob Pan wrote:
> > > > +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.

I'm a bit confused why a hyperv root parition has an AMD iommu inside
it.. I thought that was what the hv-iommu-root driver was for?

But we should fix the AMD driver to have a type (ooops that is a
troublesome bug!), and you should call add-on-top drivers like TSM
before calling the real iommu driver..

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

Maybe? I don't quite understand what you've got here..

If the VM path doesn't interact with the iommut at all, which is how
these CC cases are, then sure that might be a good idea.

I think you are going to have module dependency issues trying to get
the mshv driver's info into the iommu driver, adding a "TSM" like
driver would resolve that. ie mshv could just provide the viommu.

But, you do have a hv-iommu-root driver so it certainly can provide
the viommu too, if that can be done cleanly.

I guess think about it ?

Jason