On Mon, Mar 09, 2026 at 04:31:22AM -0700, Shameer Kolothum Thodi wrote: > > > - error_setg(errp, "NVIDIA Tegra241 CMDQV is unsupported"); > > > - return false; > > > + Tegra241CMDQV *cmdqv = s->s_accel->cmdqv; > > > + > > > + if (!iommufd_backend_alloc_viommu(idev->iommufd, idev->devid, > > > + > > > + IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV, > > if the only think that differs compared to no cmdq is the type, ie. > > > > IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV vs > > IOMMU_VIOMMU_TYPE_TEGRA241_CMDQV > > > > + passing true args, maybe you can just record the type of the cmdqv > > + that is being used in the smmu_accel device. Then you can get rid of > > + alloc and free > > It is not just the type. Based on the type we also need to pass, > > * @data_len: Length of the type specific data > * @__reserved: Must be 0 > * @data_uptr: User pointer to a driver-specific virtual IOMMU data > * > > And the above is implementation specific. > > If our idea of the "ops" is to allow easier support for different > implementations in future, it probably makes sense to keep this.
Any future "cmdqv" will likely have a different viommu type. So, essentially this is just a viommu type override, as Eric pointed out above. What we actually need to expose per viommu is type/data_len. The data_uptr can be a union viommu_data in the accel structure? Nicolin
