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

[Jacob Pan]

Hi Jason,

On Mon, 28 Sep 2026 20:03:28 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:

> 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?
> 
You are right, AMD iommu driver should never load in hyperv root.
I introduced this check in AMD driver for completeness as part of the
generic iommufd change.
https://lore.kernel.org/linux-iommu/20260925190742.1575380-3-jacob.pan@xxxxxxxxxxxxxxxxxxx/T/#u

> But we should fix the AMD driver to have a type (ooops that is a
> troublesome bug!),
Agreed.

> and you should call add-on-top drivers like TSM
> before calling the real iommu driver..
> 
I am not seeing a need for mshv to use the add-on driver like TSM,
since MSHV is not layered on top of a physical IOMMU driver.

Also, we don't have a T=0 to T=1 transition, our intended external
attach can be transitioned from a blocked domain, not from a paging
domain to external.

> > > 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 do think keeping the hv-iommu-root route is cleaner and logical. I
misunderstood your comment about "hyperv should be a TSM".

> 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.
> 
I introduced a similar registration interface in hv-common to solve the
module dep issue. Will look into if I can leverage the vIOMMU helper
here.

> 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 ?
Yes, my RFC has hv-iommu-root provide the hypervisor vIOMMU directly,
and I think the resulting layering is clean. Could you review that
approach in the MSHV iommufd RFC thread? 

> 
> Jason