Re: [PATCH v3 13/32] hw/arm/tegra241-cmdqv: Implement CMDQV vIOMMU alloc/free

[Nicolin Chen <nicolinc@nvidia.com>]

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