[PATCH v10 11/13] iommu/arm-smmu-v3: Add SVA device feature

[Jean-Philippe Brucker]

Hi,

On Tue, Dec 15, 2020 at 01:09:29AM +0000, Krishna Reddy wrote:
> Hi Jean,
> 
> > +bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
> > +       if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
> > +               return false;
> +
> > +       /* SSID and IOPF support are mandatory for the moment */
> > +       return master->ssid_bits && arm_smmu_iopf_supported(master); }
> > +
> 
> Tegra Next Gen SOC has arm-smmu-v3 and It doesn't have support for PRI interface.
> However, PCIe client device has capability to handle the page faults on its own when the ATS translation fails.
> The PCIe device needs SVA feature enable without PRI interface supported at arm-smmu-v3.
> At present, the SVA feature enable is allowed only if the smmu/client device has PRI support. 
> There seem to be no functional reason to make pri_supported as a pre-requisite for SVA enable.

The pri_supported check allows drivers to query whether the SMMU is
compatible with their capability. It's pointless, for example, to enable
SVA for a PRI-capable device if the SMMU doesn't support PRI.

I agree that we should let a device driver enable SVA if it supports some
form of IOPF. Perhaps we could extract the IOPF capability from
IOMMU_DEV_FEAT_SVA, into a new IOMMU_DEV_FEAT_IOPF feature. Device drivers
that rely on PRI or stall can first check FEAT_IOPF, then FEAT_SVA, and
enable both separately. Enabling FEAT_SVA would require FEAT_IOPF enabled
if supported. Let me try to write this up.

Thanks,
Jean

> Can SVA enable be supported for pri_supported not set case as well? 
> Also, It is noticed that SVA  enable on Intel doesn't need pri_supported set. 
> 
> -KR