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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3D56C433E6 for ; Mon, 11 Jan 2021 19:29:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7839F221F5 for ; Mon, 11 Jan 2021 19:29:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7839F221F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/xzvRyc2VHC7/suXwKuO0cYiDO+FnxlvrX4hKPtKuIg=; b=PtKwt//EwsAcRaS29y3chnRz+ WWhN+hEQHXNYiDPSgVO/noX556Z7YG+NtNUMEAhlR+jmzrSyzarBalCCZ430YCKyGqvlbhjOQ4ypj Wo/yKVUvnRe5kqcYfVHpHYllCjfNBorqlWoq8spFUDazMqqXOZBJ1qlt86oscYAIQ6MjkkuitD0Pq TKpXpoWyInam9LQNiIzeqYFAJAZL7uppy1TguuDPtqDMSORtQt6LFvZIokdwdN72OQGEXeU/5s3+j Tq40aluZQ1T5EIdpnzxawO/Ljrd4I0fe4GHHhY2vqQF0jKknkGXNDlUtPUnYTOaMCjWTGJzjGWPqF xbHT3mSHg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kz2r9-0001Cr-GJ; Mon, 11 Jan 2021 19:27:59 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kz2r6-0001Aw-HW for linux-arm-kernel@lists.infradead.org; Mon, 11 Jan 2021 19:27:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 081BF101E; Mon, 11 Jan 2021 11:27:51 -0800 (PST) Received: from [10.57.56.43] (unknown [10.57.56.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E77C23F719; Mon, 11 Jan 2021 11:27:49 -0800 (PST) Subject: Re: [PATCH] iommu/arm-smmu-v3: Handle duplicated Stream IDs from other masters To: Will Deacon , Ajay Kumar References: <20210107093340.15279-1-ajaykumar.rs@samsung.com> <20210107130319.GA2986@willie-the-truck> From: Robin Murphy Message-ID: <5e047da1-6619-c716-927c-ae07a90f1597@arm.com> Date: Mon, 11 Jan 2021 19:27:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210107130319.GA2986@willie-the-truck> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210111_142756_673311_A1C48C32 X-CRM114-Status: GOOD ( 23.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, iommu@lists.linux-foundation.org, robh+dt@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-01-07 13:03, Will Deacon wrote: > On Thu, Jan 07, 2021 at 03:03:40PM +0530, Ajay Kumar wrote: >> When PCI function drivers(ex:pci-endpoint-test) are probed for already >> initialized PCIe-RC(Root Complex), and PCIe-RC is already bound to SMMU, >> then we encounter a situation where the function driver tries to attach >> itself to the smmu with the same stream-id as PCIe-RC and re-initialize >> an already initialized STE. This causes ste_live BUG_ON() in the driver. Note that this is actually expected behaviour, since Stream ID aliasing has remained officially not supported until a sufficiently compelling reason to do so appears. I always thought the most likely scenario would be a legacy PCI bridge with multiple devices behind it, but even that seems increasingly improbable for a modern SMMUv3-based system to ever see. > I don't understand why the endpoint is using the same stream ID as the root > complex in this case. Why is that? Is the grouping logic not working > properly? It's not so much that it isn't working properly, it's more that it needs to be implemented at all ;) >> There is an already existing check in the driver to manage duplicated ids >> if duplicated ids are added in same master device, but there can be >> scenarios like above where we need to extend the check for other masters >> using the same stream-id. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 +++++++++++++++++++++ >> 1 file changed, 33 insertions(+) > > It doesn't feel like the driver is the right place to fix this, as the same > issue could surely occur for other IOMMUs too, right? In which case, I think > we should avoid getting into the situation where different groups have > overlapping stream IDs. Yes, this patch does not represent the correct thing to do either way. The main reason that Stream ID aliasing hasn't been supported so far is that the required Stream ID to group lookup is rather awkward, and adding all of that complexity just for the sake of a rather unlikely possibility seemed dubious. However, PRI support has always had a more pressing need to implement almost the same thing (Stream ID to device), so once that lands we can finally get round to adding the rest of proper group support relatively easily. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel