From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11F3CD0EE11 for ; Tue, 25 Nov 2025 18:05:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2zQw1ZszC+0ghGpDQz1n44wKsayX1m6zRZNomnYncgk=; b=eECK2uzKv0IViqmdfOiXr16tS5 KGqUgpAxt6YzIpY90CuqAKladdA4m7YVIWxJpahZUhyAuT4FU4MgB+9sJ0RwIrIB1g0/gJgbteHkK 1WAId9lXdvGtQhrYXWOwkXV9YVmP1ovw1TU8AfZPrunUr4/crgvul8toYL/diZtQnn6LBVnHh7IOI DqDCUhe9vHByLmDzPHRxYSemhhrbl+W6SvrV+RbkHOtUV2j99Di5XUA4lBkmQAH3yyDXtHJDZTbXq IJtfNXmtCQVFQgaMqxPWG6iLu7KjnfiqJcA0zXE44HfwJOaHhj9j/E6vKHIWmFmnMPEyPxLwi5Vs6 Fwt4O4Rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNxQF-0000000DjV8-3kim; Tue, 25 Nov 2025 18:05:51 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vNxQE-0000000DjUs-30hP for linux-arm-kernel@lists.infradead.org; Tue, 25 Nov 2025 18:05:50 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D38F2601AF; Tue, 25 Nov 2025 18:05:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 992C0C4CEF1; Tue, 25 Nov 2025 18:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764093949; bh=YP4UWtXPGEMDVAxQ9+yA4ItyyOw9cyvtV82OlT9k77Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D9rfUIYy50ku+otqD5fIKODl3ucpdu6EAXrcka3ekIqu3VOeXsForELG454WXH8aV aZZiteBWBkpVqgJehBKptNXMGI+T1a+0yd5IMSLF9hL8TZYa2I/uMyqEWd8zbLD7II hyh85i/o2HLsrwZLxMlAOGFrjdoiaboIFTnOigxOXp+YULlO4DaNGHgN7h0ngd9GNV IFMW6c3lKx94961pLJ5MHHhAs2K1UQ4Hzh69AFH7XY9Aht6fnB2MNccGymGGej6NYk 5o9BR3RWrCJAYDL+N4sFXo2Ln8RgDPjAFzJBOmA5ex4kdf7NqXabZxd3Ehgi4J5fG4 eRztOzrvrYrog== From: Will Deacon To: Robin Murphy , Joerg Roedel , Stephan Gerhold Cc: catalin.marinas@arm.com, kernel-team@android.com, Will Deacon , Rob Clark , Manivannan Sadhasivam , Johan Hovold , Bjorn Andersson , iommu@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal Date: Tue, 25 Nov 2025 18:05:40 +0000 Message-Id: <176408774799.1871149.15645186594285769855.b4-ty@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250821-arm-smmu-qcom-all-smr-v1-1-7f5cbbceac3e@linaro.org> References: <20250821-arm-smmu-qcom-all-smr-v1-1-7f5cbbceac3e@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 21 Aug 2025 10:33:53 +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. > > [...] Applied to iommu (arm/smmu/updates), thanks! [1/1] iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-metal https://git.kernel.org/iommu/c/5583a55e074b I chatted off-list with Robin about this and we agreed that it's the best approach for now. Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev