Re: [PATCH v4 3/8] iommu/arm-smmu-v3: Optimize range invalidation for latency

On Wed, Aug 05, 2026 at 04:15:21PM -0300, Jason Gunthorpe wrote:
> @@ -2633,11 +2681,17 @@ static void __arm_smmu_domain_inv_range(struct arm_smmu_tlbi *tlbi,
>  		case INV_TYPE_S2_VMID:
>  			cmd = arm_smmu_make_cmd_tlbi(cur->size_opcode,
>  						     0, cur->id);
> -			arm_smmu_inv_to_cmdq_batch(cur, &cmds, &cmd, tlbi);
> +			used_s12_vmall = arm_smmu_inv_to_cmdq_batch(cur, &cmds,
> +								    &cmd, tlbi);
>  			break;
>  		case INV_TYPE_S2_VMID_S1_CLEAR:
> -			/* CMDQ_OP_TLBI_S12_VMALL already flushed S1 entries */
> -			if (arm_smmu_inv_size_too_big(cur->smmu, tlbi))
> +			/*
> +			 * S2_VMID used CMDQ_OP_TLBI_S12_VMALL which already
> +			 * flushed S1 entries. These two types always come in
> +			 * pairs and arm_smmu_inv_cmp() ensures that they are
> +			 * consecutive in the list.
> +			 */
> +			if (used_s12_vmall)
>  				break;

AI noticed that this has a gap if the invalidation list contains more
than one instance, then we could leak the vmall property across the
two instances if concurrently the second instance was being trashed.

I fixed it by using a list pointer to keep track of the exact pairs
instead of a simple bool

Jason