Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6691070pxv; Thu, 29 Jul 2021 23:13:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSLlB2wPykiRW1qNufkWVe4cMdLp79ZmBRP4ExZLeAhnoTYU7d+qUU8JgU6QQQyyxUwSyI X-Received: by 2002:a05:6638:14c1:: with SMTP id l1mr806506jak.97.1627625632903; Thu, 29 Jul 2021 23:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627625632; cv=none; d=google.com; s=arc-20160816; b=p3J0ddYh7qDfTlRMnJgIUaXpQMXbOA+DRkQO9PzG3y6JkgIOWlJA6KodkydrHaEWju l3aFj9KboKrZhng6mWZ1fBjZIDJreOFwBCj9/3UY3cxqy6kAIiNCMR7jpuVKpgl0pHFd LqM+HUnJO9HegCpd5WyEzN9khfC4dGRvBkuF93LrhuMmPloSOhWrFDT3v3TXw2gCxhyW MQdzXTwhRQSviFc6dt7VObY+iNFuNt0DZJ8dx8BBJnFRBEw/VRHqmHigXjgFDSRwCgSo 9dTIvmbWBWukTv6H7AcawftHPlqP5VqA0X6K8/FP7Bar5juCundOqJTkm7cDmIzbV/0v 3ZIg== 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 :to:subject:cc; bh=5Ewk/n0AbU+keXPhMQKYhJRBIP/MaCuqp0f+uFVJiFU=; b=i5e/RYC55A5TBPVTRFLtziby9bi19vbMlIujAzEsM95dflFh0nwjBxcTa7It0fmudV I7hL6LQBgOR4LErtGo3GevsDyfV8292hDeHs/2g9OByUcMj2+c+J36nqZhpz0P/TVTtW tw0l+qakS9ygTImriVpKSaN7QnW4UsH5Hdb3Xgd6QRfJUK1lFFNtAndnfFJVBf8y42m8 P4A7gbrRtnrmveFM7s1BDtwIPWw5fBnbwkAeLGr9kQC2+NGCMCkC7q/rgngP76vTsIyS IVoKHUthY3yAakp0qh/pvGx5AOG6a2gkB9WIB/SxEcMFLkeRdImOA7fWLYlE0YqLyNlo kkTg== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o11si675602ilg.108.2021.07.29.23.13.41; Thu, 29 Jul 2021 23:13:52 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237056AbhG3GMy (ORCPT + 99 others); Fri, 30 Jul 2021 02:12:54 -0400 Received: from mga06.intel.com ([134.134.136.31]:19641 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237060AbhG3GMx (ORCPT ); Fri, 30 Jul 2021 02:12:53 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10060"; a="274111327" X-IronPort-AV: E=Sophos;i="5.84,281,1620716400"; d="scan'208";a="274111327" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2021 23:12:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,281,1620716400"; d="scan'208";a="465345165" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by orsmga008.jf.intel.com with ESMTP; 29 Jul 2021 23:12:46 -0700 Cc: baolu.lu@linux.intel.com, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suravee.suthikulpanit@amd.com, john.garry@huawei.com, dianders@chromium.org Subject: Re: [PATCH v2 19/24] iommu: Expose DMA domain strictness via sysfs To: Robin Murphy , joro@8bytes.org, will@kernel.org References: From: Lu Baolu Message-ID: Date: Fri, 30 Jul 2021 14:10:28 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/28/21 11:58 PM, Robin Murphy wrote: > The sysfs interface for default domain types exists primarily so users > can choose the performance/security tradeoff relevant to their own > workload. As such, the choice between the policies for DMA domains fits > perfectly as an additional point on that scale - downgrading a > particular device from a strict default to non-strict may be enough to > let it reach the desired level of performance, while still retaining > more peace of mind than with a wide-open identity domain. Now that we've > abstracted non-strict mode as a distinct type of DMA domain, allow it to > be chosen through the user interface as well. > > Signed-off-by: Robin Murphy > --- > Documentation/ABI/testing/sysfs-kernel-iommu_groups | 2 ++ > drivers/iommu/iommu.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups > index eae2f1c1e11e..43ba764ba5b7 100644 > --- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups > +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups > @@ -42,6 +42,8 @@ Description: /sys/kernel/iommu_groups//type shows the type of default > ======== ====================================================== > DMA All the DMA transactions from the device in this group > are translated by the iommu. > + DMA-FQ As above, but using batched invalidation to lazily > + remove translations after use. > identity All the DMA transactions from the device in this group > are not translated by the iommu. > auto Change to the type the device was booted with. > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index eecb5657de69..5a08e0806cbb 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -3265,6 +3265,8 @@ static ssize_t iommu_group_store_type(struct iommu_group *group, > req_type = IOMMU_DOMAIN_IDENTITY; > else if (sysfs_streq(buf, "DMA")) > req_type = IOMMU_DOMAIN_DMA; > + else if (sysfs_streq(buf, "DMA-FQ")) > + req_type = IOMMU_DOMAIN_DMA_FQ; > else if (sysfs_streq(buf, "auto")) > req_type = 0; > else > Reviewed-by: Lu Baolu Best regards, baolu