[PATCH] iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal

[Will Deacon]

On Thu, Aug 21, 2025 at 10:33:53AM +0200, Stephan Gerhold wrote:
> Some platforms (e.g. SC8280XP and X1E) support more than 128 stream
> matching groups. This is more than what is defined as maximum by the ARM
> SMMU architecture specification. Commit 122611347326 ("iommu/arm-smmu-qcom:
> Limit the SMR groups to 128") disabled use of the additional groups because
> they don't exhibit the same behavior as the architecture supported ones.
> 
> It seems like this is just another quirk of the hypervisor: When running
> bare-metal without the hypervisor, the additional groups appear to behave
> just like all others. The boot firmware uses some of the additional groups,
> so ignoring them in this situation leads to stream match conflicts whenever
> we allocate a new SMR group for the same SID.
> 
> The workaround exists primarily because the bypass quirk detection fails
> when using a S2CR register from the additional matching groups, so let's
> perform the test with the last reliable S2CR (127) and then limit the
> number of SMR groups only if we detect that we are running below the
> hypervisor (because of the bypass quirk).
> 
> Fixes: 122611347326 ("iommu/arm-smmu-qcom: Limit the SMR groups to 128")
> Signed-off-by: Stephan Gerhold <stephan.gerhold at linaro.org>
> ---
> I modified arm_smmu_find_sme() to prefer allocating from the SMR groups
> above 128 (until they are all used). I did not see any issues, so I don't
> see any indication that they behave any different from the others.
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 27 +++++++++++++++++----------
>  1 file changed, 17 insertions(+), 10 deletions(-)

Is the existing workaround causing you problems somehow? Limiting the SMR
groups to what the architecture allows still seems like the best bet to
me unless there's a compelling reason to do something else.

Will