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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 BE4F5C433ED for ; Fri, 16 Apr 2021 15:23:45 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 7F8C561184 for ; Fri, 16 Apr 2021 15:23:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F8C561184 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.111863.213908 (Exim 4.92) (envelope-from ) id 1lXQJk-0004vj-2S; Fri, 16 Apr 2021 15:23:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 111863.213908; Fri, 16 Apr 2021 15:23:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lXQJj-0004vc-Vd; Fri, 16 Apr 2021 15:23:35 +0000 Received: by outflank-mailman (input) for mailman id 111863; Fri, 16 Apr 2021 15:23:34 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lXQJi-0004vU-Ru for xen-devel@lists.xenproject.org; Fri, 16 Apr 2021 15:23:34 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lXQJh-0000b6-ML; Fri, 16 Apr 2021 15:23:33 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lXQJh-00041R-EI; Fri, 16 Apr 2021 15:23:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=id6bSkFigLGMm1fydDiXIgZj0L0d3um9KFzHEjDyr0o=; b=ss6a7HT/pHjPP3u2zU+LDCTMlA VXRyliwxTgnryzYysQlJqqzyQQQ2+6XdZAyN/jS4V+64EG1TWjIz5MLU8DJWYQmZ0L9wAEDgissht WRKnYIW2kxv2pnKixXm65ypres5lAjMIRSIEUoxFhThLaJYnL990oAJOTu4P8Lyfij2k=; Subject: Re: [PATCH] xen/arm: smmuv1: Revert associating the group pointer with the S2CR To: Rahul Singh Cc: xen-devel , Bertrand Marquis , Stefano Stabellini , Volodymyr Babchuk References: <6e75d112-6cc1-4b7c-9751-4064b3250dbf@xen.org> From: Julien Grall Message-ID: <8569c856-8838-e5d1-b653-e7eb476dacdc@xen.org> Date: Fri, 16 Apr 2021 16:23:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit On 16/04/2021 16:01, Rahul Singh wrote: > Hi Julien, Hi Rahul, > >> On 16 Apr 2021, at 3:35 pm, Julien Grall wrote: >> >> Hi, >> >> On 16/04/2021 12:25, Rahul Singh wrote: >>> Revert the code that associates the group pointer with the S2CR as this >>> code causing an issue when the SMMU device has more than one master >>> device. >> >> It is not clear to me why this change was first added. Are we missing any feature when reverting it? > > This feature was added when we backported the code from Linux to fix the stream match conflict issue > as part of commit "xen/arm: smmuv1: Intelligent SMR allocation”. > > This is an extra feature added to allocate IOMMU group based on stream-id. If two device has the > same stream-id then we assign those devices to the same group. If we revert the patch, then it would not be possible to use the SMMU if two devices use the same stream-id. Is that correct? > This code was removed from Linux > later point in time when IOMMU group handling is done by Linux code not by a specific IOMMU driver. Right.... But Linux still support that option. Is that correct? > Therefore I think it is ok revert the code. I am ok with the principle of (partially) reverting patch to unblock the situation. But I have to admit, I don't quite understand why this is reverted rather than fixed. Cheers, -- Julien Grall