[PATCH v1 07/12] iommu/arm-smmu-v3: Implement arm_smmu_get_viommu_size and arm_vsmmu_init

Tian, Kevin kevin.tian at intel.com
Fri Jun 13 00:36:30 PDT 2025


> From: Nicolin Chen <nicolinc at nvidia.com>
> Sent: Friday, June 13, 2025 1:18 AM
> 
> On Thu, Jun 12, 2025 at 08:20:30AM +0000, Tian, Kevin wrote:
> > > From: Nicolin Chen <nicolinc at nvidia.com>
> > > Sent: Tuesday, June 10, 2025 1:14 AM
> > >
> > > +int arm_smmu_get_viommu_size(enum iommu_viommu_type
> > > viommu_type,
> > > +			     struct device *dev, size_t *viommu_size)
> > > +{
> > > +	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 -EOPNOTSUPP;
> > > +
> > > +	/*
> > > +	 * FORCE_SYNC is not set with FEAT_NESTING. Some study of the
> > > exact HW
> > > +	 * defect is needed to determine if arm_vsmmu_cache_invalidate()
> > > needs
> > > +	 * any change to remove this.
> > > +	 */
> > > +	if (WARN_ON(smmu->options &
> > > ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
> > > +		return -EOPNOTSUPP;
> > > +
> > > +	/*
> > > +	 * Must support some way to prevent the VM from bypassing the
> > > cache
> > > +	 * because VFIO currently does not do any cache maintenance.
> > > canwbs
> > > +	 * indicates the device is fully coherent and no cache maintenance is
> > > +	 * ever required, even for PCI No-Snoop. S2FWB means the S1 can't
> > > make
> > > +	 * things non-coherent using the memattr, but No-Snoop behavior is
> > > not
> > > +	 * effected.
> > > +	 */
> > > +	if (!arm_smmu_master_canwbs(master) &&
> > > +	    !(smmu->features & ARM_SMMU_FEAT_S2FWB))
> > > +		return -EOPNOTSUPP;
> > > +
> > > +	if (viommu_type != IOMMU_VIOMMU_TYPE_ARM_SMMUV3)
> > > +		return -EOPNOTSUPP;
> >
> > it's more intuitive to check it first.
> 
> Agreed. But I kinda intentionally left it here. The SMMU driver
> will have something like an impl_op->get_viommu_size in the HW
> queue series. That can simply insert a piece:
> ===============================================================
> @@ -415,6 +415,12 @@ int arm_smmu_get_viommu_size(enum
> iommu_viommu_type viommu_type,
>             !(smmu->features & ARM_SMMU_FEAT_S2FWB))
>                 return -EOPNOTSUPP;
> 
> +       if (smmu->impl_ops && smmu->impl_ops->vsmmu_size &&
> +           viommu_type == smmu->impl_ops->vsmmu_type) {
> +               *viommu_size = smmu->impl_ops->vsmmu_size;
> +               return 0;
> +       }
> +
>         if (viommu_type != IOMMU_VIOMMU_TYPE_ARM_SMMUV3)
>                 return -EOPNOTSUPP;
> 
> ===============================================================

Oh I see.

> 
> Otherwise, this following patch has to move the type check again.
> 
> > btw does it make sense to also add below here?
> > 	if (s2_parent->smmu != master->smmu)
> > 		return ERR_PTR(-EINVAL);
> 
> I can't find a legit reason to forward the s2_parent to run this
> sanity. "struct device *" is forwarded since the driver needs to
> know the smmu pointer: A for the compatibility checks; b for the
> smmu->impl_ops mentioned above.
> 

yes



More information about the linux-arm-kernel mailing list