On Thu, Jun 19, 2025 at 03:53:25PM -0300, Jason Gunthorpe wrote:
On Thu, Jun 19, 2025 at 11:47:24AM +0000, Pranjal Shrivastava wrote:
I'm not sure if I get this right.. if the user (while porting a VMM or something) mistakenly passes *type == IOMMU_HW_INFO_TYPE_INTEL_VTD here, they'll get impl-specific info?
It should call the impl hw_info which should fail?
+static void *tegra241_cmdqv_hw_info(struct arm_smmu_device *smmu, u32 *length,
u32 *type)+{
- if (*type != IOMMU_HW_INFO_TYPE_TEGRA241_CMDQV)
return ERR_PTR(-EOPNOTSUPP);If impl ops is null/etc then it fails:
if (!impl_ops || !impl_ops->hw_info)return ERR_PTR(-EOPNOTSUPP);Where does IOMMU_HW_INFO_TYPE_INTEL_VTD return something?
I mean, the check in the driver (for e.g. arm-smmu-v3) is:
if (*type != IOMMU_HW_INFO_TYPE_DEFAULT && *type != IOMMU_HW_INFO_TYPE_ARM_SMMUV3)
// call impl_ops
My point is that in-case someone passed INTEL_VTD type, we would end up calling impl_ops->hw_info and then the impl_ops->hw_info shall check for the type to return -EOPNOTSUPP. Either we should clearly mention that each impl_op implementing hw_info *must* add another type and check for it OR we could have sub-types for implementations extending a main type somehow?
I agree in that case the impl-specific driver needs to check the type, but shouldn't we simply return from here itself if the type isn't arm-smmu-v3?
Then how do you return IOMMU_HW_INFO_TYPE_TEGRA241_CMDQV?
The current version is just fine with a doc string mentioning type checks within impl_ops->hw_info OR we could have sub-types for implementations extending some architectural IOMMU.
I'm just trying to avoid weird bug reports in the future because some impl didn't check for their type.
Jason
Thanks Praan