Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp924311pxv; Fri, 9 Jul 2021 12:23:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwa76XJ20kTTajCQ/X7HIpSDT/eyrClVTrOiKq7vZA+iqXZIruZkIXIaV9Wp4M+8WtWu4L3 X-Received: by 2002:a05:6402:1cb8:: with SMTP id cz24mr37984298edb.319.1625858613652; Fri, 09 Jul 2021 12:23:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625858613; cv=none; d=google.com; s=arc-20160816; b=Gnmi+xIgBcir4QzW0mOQSwtfNLgTEA0IZ5phQIIwT7330H6YCeSieEbfYWkjeMiLFr RPwmqa7Le2/eLI5AjqIKlxRbQyyy3Nv6/bFKPQEhnb1Y4n7yzCk2zsaJXqG3ZLhAfZQM KRCLgGHMNM1+L5RGJg8tTgXLVPd5DoyHUUTk4C4clfSCVvOrFpjrG9CqvFiNLHkQFYyv mCQ2lkFI0ePGJlYk1Vo/gd9eL6kd7+/XyvaJ+2N4cQWL2txa73+Fb3evs78dyouu81XP IugAm7cxZPgOKgKq4744qFenXYbIw/YPcpHnec9k1q2U3MaK7cJoOx5UKFq7yPWz2mX2 OKoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=yUzp5am7pMlsY+8WAF8oxsWB4DxSc58loJetjybxOws=; b=qBHFMxtIGiRSvjRN0mU4+eA8V43RA3TeB2OcjeViYnAAUKArInbPyEma+1JeQmMup9 +4pdN/2xesdrvUtJDeALe37CJ0HEnf5h2w++9r12ifldapAMEf6fPvc59S6Be/7ZAHRw mr5xArLmZ+JYaOdjipq+xuvzjAktIF2guh/m7LgmcNLc9D66CstiaNcMj1JdtYWBAjzQ 8faCeSEOqBL0JOJvYAZ71K2hjfzxr+A2Ts35/mutMHY0K6eEaMYjvRViL2Ez0HQrJf5e cHk1U5vTMSHpmRR4IHX69epKwBPqsT9S1a40K1khzLh0LxRb4HTBODtx10zGREanJ5el /u0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s11si8587739edh.483.2021.07.09.12.23.10; Fri, 09 Jul 2021 12:23:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231247AbhGITYm (ORCPT + 99 others); Fri, 9 Jul 2021 15:24:42 -0400 Received: from foss.arm.com ([217.140.110.172]:58602 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229552AbhGITYl (ORCPT ); Fri, 9 Jul 2021 15:24:41 -0400 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 3396531B; Fri, 9 Jul 2021 12:21:57 -0700 (PDT) Received: from [10.57.33.207] (unknown [10.57.33.207]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B38DD3F66F; Fri, 9 Jul 2021 12:21:52 -0700 (PDT) Subject: Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC To: Joerg Roedel , Doug Anderson Cc: Ulf Hansson , Linux Doc Mailing List , Peter Zijlstra , linux-pci@vger.kernel.org, Konrad Dybcio , Thierry Reding , Joel Fernandes , Rajat Jain , Will Deacon , Rob Clark , Saravana Kannan , Jonathan Corbet , quic_c_gdjako@quicinc.com, Linux ARM , Viresh Kumar , Veerabhadrarao Badiganti , "Paul E. McKenney" , linux-arm-msm , Bjorn Helgaas , Sonny Rao , Vlastimil Babka , Randy Dunlap , Linux MMC List , Adrian Hunter , LKML , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , iommu@lists.linux-foundation.org, Andrew Morton , "Maciej W. Rozycki" References: <20210624171759.4125094-1-dianders@chromium.org> From: Robin Murphy Message-ID: <0a2042ff-1604-d32d-35a7-d4df8f591459@arm.com> Date: Fri, 9 Jul 2021 20:21:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-07-08 09:08, Joerg Roedel wrote: > On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote: >> a) Nothing is inherently broken with my current approach. >> >> b) My current approach doesn't make anybody terribly upset even if >> nobody is totally in love with it. > > Well, no, sorry :) > > I don't think it is a good idea to allow drivers to opt-out of the > strict-setting. This is a platform or user decision, and the driver > should accept whatever it gets. > > So the real question is still why strict is the default setting and how > to change that. It's occurred to me whilst hacking on the relevant area that there's an important point I may have somewhat glossed over there: most of the IOMMU drivers that are used for arm64 do not take advantage of non-strict mode anyway. If anything it would be detrimental, since iommu-dma would waste a bunch of time and memory managing flush queues and firing off the batch invalidations while internally the drivers are still invalidating each unmap synchronously. Those IOMMUs in mobile and embedded SoCs are also mostly used for media devices, where the buffers are relatively large and change relatively infrequently, so they are less likely to gain significantly from supporting non-strict mode. It's primarily the Arm SMMUs which get used in the more "x86-like" paradigm (especially in larger systems) of being stuck in front of everything including networking/storage/PCIe/etc. where the workloads are far more varied. Robin. > Or document for the users that want performance how to > change the setting, so that they can decide. > > Regards, > > Joerg > > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu >