Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5112005pxj; Wed, 9 Jun 2021 09:23:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrLybbcS/EKxUKySkBeaW+XADi19M5Z8/Y/ZRd6Msj3UntThLQ3jVm71k7SZ1UfkY2ckKT X-Received: by 2002:aa7:dd0b:: with SMTP id i11mr254832edv.51.1623255784893; Wed, 09 Jun 2021 09:23:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623255784; cv=none; d=google.com; s=arc-20160816; b=Ik2rDlVJTA98HwBXBy3LOD4oroHkOq0B4h7ZjCkawRrIFuVfmRT73GHursMIionQaA nkfwoThsn5JS25yn0QzbLAPmrxiDJXD5F3x9DChinz058msI9N6NGObXYlZBiM4df7kq i3jJwOvCY1wYivQKshJMwbVGB3nV+3UtGh2QyPVY1R0NjzUp/BZWegtreFp562Ufd8rJ 4Pxdr0WRGIO8SdRE/Rc7g9lFqU+MSpXChsiLB4fKegP/vhX1+Cg7EZTlxEmrO3tXE8KC CusI8fa+Arv/RxNNxYVtcrqQ8llQqAd12b9Cb9MIls/UOlEKnT7PIXld9mLX4aCu8kDT F08g== 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=HzGcLk4AdKsp6gufhGTWqbciCdN7hGuOBk5w/KhdxkU=; b=bg/mlWQNnxVkhjy8tQnAWqnO5trqIRej89MfsuaPmtu4qt/2wlHHl4RCUb1wPxK8D7 3UiekD3oMy8rHSoJayqLGX0WC1NTLto6DhziJhvYSJ2vgTu/MZkE3aDXdWWvS505mZk6 4u5UNWuGMUcVotz9UF63Bq7puJTPTHVZJcz3ujsIFTqqpUgaEEZNpcTc7fA2TFUh2eGj gLcSVgURqqO6GXvAfxs/MQh7tDTfuTFVzBAqfcwp2O+nO7NC00Gl3apSxRjTc03P8KLN bW3JLJheUbpVMALnqwpXKnwZrlN7CTwnmn+c+HrTgpqdRJak4cuPI9DMLGF3Tktqo4nS SD4w== 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=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n5si136799edv.210.2021.06.09.09.22.40; Wed, 09 Jun 2021 09:23:04 -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=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236357AbhFIPcC (ORCPT + 99 others); Wed, 9 Jun 2021 11:32:02 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3190 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233476AbhFIPcB (ORCPT ); Wed, 9 Jun 2021 11:32:01 -0400 Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G0W1T6RGvz6J9WM; Wed, 9 Jun 2021 23:17:17 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 17:30:04 +0200 Received: from [10.47.80.201] (10.47.80.201) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 16:30:03 +0100 Subject: Re: [PATCH v11 1/3] iommu: Enhance IOMMU default DMA mode build options To: Robin Murphy , , , , CC: , , , References: <1623158308-180604-1-git-send-email-john.garry@huawei.com> <1623158308-180604-2-git-send-email-john.garry@huawei.com> From: John Garry Message-ID: Date: Wed, 9 Jun 2021 16:24:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.47.80.201] X-ClientProxiedBy: lhreml749-chm.china.huawei.com (10.201.108.199) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/06/2021 16:03, Robin Murphy wrote: > On 2021-06-08 14:18, John Garry wrote: >> From: Zhen Lei >> >> First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the >> opportunity to set {lazy|strict} mode as default at build time. Then put >> the two config options in a choice, as they are mutually exclusive. >> >> [jpg: Make choice between strict and lazy only (and not passthrough)] >> Signed-off-by: Zhen Lei >> Signed-off-by: John Garry >> --- >>   drivers/iommu/Kconfig | 35 +++++++++++++++++++++++++++++++++++ >>   drivers/iommu/iommu.c |  3 ++- >>   2 files changed, 37 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig >> index 1f111b399bca..369a3af9e5bf 100644 >> --- a/drivers/iommu/Kconfig >> +++ b/drivers/iommu/Kconfig >> @@ -90,6 +90,41 @@ config IOMMU_DEFAULT_PASSTHROUGH >>         If unsure, say N here. >> +choice >> +    prompt "IOMMU default DMA mode" >> +    depends on IOMMU_API >> +    depends on X86 || IA64 || X86_64 || ARM || ARM64 > > Simply "depends on IOMMU_DMA" should suffice, since that's now the only > place where flush queues matter. I suppose so. Configs ARM64, AMD_IOMMU, and INTEL_IOMMU all select this. > >> + >> +    default IOMMU_DEFAULT_STRICT >> +    help >> +      This option allows an IOMMU DMA mode to be chosen at build >> time, to >> +      override the default DMA mode of each ARCH, removing the need to >> +      pass in kernel parameters through command line. It is still >> possible >> +      to provide ARCH-specific or common boot options to override this >> +      option. >> + >> +      If unsure, keep the default. >> + >> +config IOMMU_DEFAULT_LAZY >> +    bool "lazy" >> +    help >> +      Support lazy mode, where for every IOMMU DMA unmap operation, the >> +      flush operation of IOTLB and the free operation of IOVA are >> deferred. >> +      They are only guaranteed to be done before the related IOVA >> will be >> +      reused. >> + >> +config IOMMU_DEFAULT_STRICT >> +    bool "strict" >> +    help >> +      For every IOMMU DMA unmap operation, the flush operation of >> IOTLB and >> +      the free operation of IOVA are guaranteed to be done in the unmap >> +      function. >> + >> +      This mode is safer than lazy mode, but it may be slower in some >> high >> +      performance scenarios. > > FWIW, as an end user who doesn't care much about the implementation > details I'd probably appreciate the actual implications being clearer, > i.e. what does "safer" mean in practice and what is it relative to? > Fine, I can mention that lazy mode means that we have reduced device isolation and a dangerous window can be created between device driver DMA unmap and zapping the mapping in the IOMMU; however still much safer than passthrough/no IOMMU, which means no isolation at all. Thanks, John