[RFC PATCH 04/30] iommu/arm-smmu-v3: Add support for PCI ATS

[Jean-Philippe Brucker]

On 03/04/17 12:42, Sunil Kovvuri wrote:
> On Mon, Apr 3, 2017 at 3:44 PM, Jean-Philippe Brucker
> <jean-philippe.brucker at arm.com> wrote:
>> On 03/04/17 09:34, Sunil Kovvuri wrote:
>>>> +static size_t arm_smmu_atc_invalidate_domain(struct arm_smmu_domain *smmu_domain,
>>>> +                                            unsigned long iova, size_t size)
>>>> +{
>>>> +       unsigned long flags;
>>>> +       struct arm_smmu_cmdq_ent cmd = {0};
>>>> +       struct arm_smmu_group *smmu_group;
>>>> +       struct arm_smmu_master_data *master;
>>>> +       struct arm_smmu_device *smmu = smmu_domain->smmu;
>>>> +       struct arm_smmu_cmdq_ent sync_cmd = {
>>>> +               .opcode = CMDQ_OP_CMD_SYNC,
>>>> +       };
>>>> +
>>>> +       spin_lock_irqsave(&smmu_domain->groups_lock, flags);
>>>> +
>>>> +       list_for_each_entry(smmu_group, &smmu_domain->groups, domain_head) {
>>>> +               if (!smmu_group->ats_enabled)
>>>> +                       continue;
>>>
>>> If ATS is not supported, this seems to increase no of cycles spent in
>>> pgtbl_lock.
>>> Can we return from this API by checking 'ARM_SMMU_FEAT_ATS' in smmu->features ?
>>
>> Sure, I can add a check before taking the lock. Have you been able to
>> observe a significant difference in cycles between checking FEAT_ATS,
>> checking group->ats_enabled after taking the lock, and removing this
>> function call altogether?
>>
>> Thanks,
>> Jean-Philippe
> 
> No, I haven't verified, was just making an observation.

Fair enough, I think avoiding the lock when ATS isn't in use makes sense.

Thanks,
Jean-Philippe