Re: [RFC PATCH v6 06/11] iommu: Add a helper to query vIOMMU hardware parameters
From: Jason Gunthorpe
Date: Fri Sep 25 2026 - 08:30:51 EST
On Fri, Sep 25, 2026 at 11:29:58AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@xxxxxxxxxx> writes:
>
> >> [ ... 18 lines skipped ... ]
> >> +int iommu_viommu_get_params(struct device *dev,
> >> + enum iommu_viommu_type type, void *params, size_t params_size)
> >> +{
> >
> > I imagined this would be a direct function call from TSM to iommu
> > driver? Is there a reason to do it this way? I think a TSM -> iommu
> > module dependency is OK
> >
>
> Do you mean that the TSM backend should call arm_smmu_get_realm_params()
> directly?
Yes
> I was trying to avoid that dependency. TSM depends only on
> iommufd, not on the SMMU driver.
I'm not sure there is a good reason to. RMM systems will always have a
SMMU.
Also TSM should only depend on iommu_driver if at all possible.
It is another reason to not like this because it pulls in a full
iommufd.ko dependency...
> Making this part of iommu_ops also simplifies supporting different
> get_params implementations for different hardware IOMMUs on the same
> architecture, if needed.
If that happens the TSM needs unique coding for all of them, and then
the direct link might be a bit of overhead.. But given people are not
making new iommus routinely (for good reason!) I would prefer to kick
that can down the road..
Jason