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: <aEsL2mxfO0x3isog@nvidia.com>
Date: Thu, 12 Jun 2025 10:18:18 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: "Tian, Kevin" <kevin.tian@...el.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

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;

===============================================================

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.

Thanks
Nicolin