Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp254969pxv; Wed, 14 Jul 2021 03:17:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzLO8d38GFWWW4d5X0ONLr5MbpE4pXsJ5DWYP1Y5ZSbJD1FPHcNLWPCPpypyvWFDs1Cx0S X-Received: by 2002:a05:6602:134f:: with SMTP id i15mr6728192iov.143.1626257836874; Wed, 14 Jul 2021 03:17:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626257836; cv=none; d=google.com; s=arc-20160816; b=EZk2l0Zpqcd440wDb5Fua+w58YrDyusPprSRMYZfsDsBZZrDjfty3Fjw2F4IoXmcd4 DN8iAVOKEL/8BEJNS+jFs49Ghaer6swXYCiUJxncEtDZsIXQHGs0CLgz7CuH2MI9lR/K o5nnYONeJ28cJ3/jcoVlMPuEBEx2MWtpNgqcevZECcfbRmnTPXxoQYbUyRsdWWaQy0Tk k9dDLFZ2S6o1yeQWAdtvGgCPmOYTs1j0n+qzmeAveN5GhyZLftIOCzGOofvl9pH3I5/g uKZ9OANEDY3ZlbGJI9klE2KTWCKxeyz/ehNddeBTRn93Fa7VcrUzmZmKPdlUU8yVVa/o 486g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=QeXCdwP3AVWe9ljwLK7+niYqwH7Yl9CrBfFxnQUAyik=; b=SNQ/gwdXKH9F6S1ky1Wvwz+szK1nEzLsFlwPWXkN3fUq1EZr/jgdzRGRjJ3MhJYodl 7qVqp43YdJihDXprhsakZr/X83VhEWriUyBUEi1fSGdz0upfijWWUHeaxzeJLAFE0vmO DC0Ng3a7n1mDDbEaV6jiF650cA3lHI60wAxOzFOEc3wNa/TC64EjjEY+wUMAmoFnniJF 4PU9CCcz/5Ne7rEjHC7TdtEklOiGZUHUOaTjQnl6kA0RiOpMhjVpIWsnUODrNkRDBqOv dfQ+0v7cunfoCmSW5AEfuJ7hddUcFU/z/P+qtiY/A1jAdwhYz09K3EePvCW7AqUcHP2r qbjA== 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=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c7si2178909iot.72.2021.07.14.03.17.04; Wed, 14 Jul 2021 03:17:16 -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=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239021AbhGNKSW (ORCPT + 99 others); Wed, 14 Jul 2021 06:18:22 -0400 Received: from 8bytes.org ([81.169.241.247]:37742 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238728AbhGNKSW (ORCPT ); Wed, 14 Jul 2021 06:18:22 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id C73C1352; Wed, 14 Jul 2021 12:15:27 +0200 (CEST) Date: Wed, 14 Jul 2021 12:15:20 +0200 From: Joerg Roedel To: Robin Murphy Cc: Doug Anderson , 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" , Andrew Morton , "Maciej W. Rozycki" Subject: Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC Message-ID: References: <20210624171759.4125094-1-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, On Fri, Jul 09, 2021 at 02:56:47PM +0100, Robin Murphy wrote: > As I mentioned before, conceptually I think this very much belongs in sysfs > as a user decision. We essentially have 4 levels of "strictness": > > 1: DMA domain with bounce pages > 2: DMA domain > 3: DMA domain with flush queue > 4: Identity domain Together with reasonable defaults (influenced by compile-time options) it seems to be a good thing to configure at runtime via sysfs. We already have CONFIG_IOMMU_DEFAULT_PASSTHROUGH, which can probably be extended to be an option list: - CONFIG_IOMMU_DEFAULT_PASSTHROUGH: Trusted devices are identity mapped - CONFIG_IOMMU_DEFAULT_DMA_STRICT: Trusted devices are DMA mapped with strict flush behavior on unmap - CONFIG_IOMMU_DEFAULT_DMA_LAZY: Trusted devices are DMA mapped with flush queues for performance Untrusted devices always get into the DMA domain with bounce pages by default. The defaults can be changed at runtime via sysfs. We already have basic support for runtime switching of the default domain, so that can be re-used. Regards, Joerg