linux-kernel - RE: [PATCH v1 07/12] iommu/arm-smmu-v3: Implement arm_smmu_get_viommu_size and arm_vsmmu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB52768A39F3D0594B3A79686A8C77A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 13 Jun 2025 07:36:30 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>
CC: "jgg@...dia.com" <jgg@...dia.com>, "will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>, "joro@...tes.org"
	<joro@...tes.org>, "ddutile@...hat.com" <ddutile@...hat.com>, "Liu, Yi L"
	<yi.l.liu@...el.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"jsnitsel@...hat.com" <jsnitsel@...hat.com>, "praan@...gle.com"
	<praan@...gle.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>, "baolu.lu@...ux.intel.com"
	<baolu.lu@...ux.intel.com>
Subject: RE: [PATCH v1 07/12] iommu/arm-smmu-v3: Implement
 arm_smmu_get_viommu_size and arm_vsmmu_init

> From: Nicolin Chen <nicolinc@...dia.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@...dia.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