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;
IronPort-SDR: SHfz12V4XM5GN/V3nwuTVG1Wmh7khPlWkwM6xa0ally7u2cMlRA9cuyPXkAnOf0uhr+WdOuanJ
 zffATOqw/iEg==
IronPort-SDR: HGSyKzehp43FjYp0rgwHlcVfxC/9mqaKeNAcAIonOHPHnDnfDerhV26RKa823oHg4ZqVAypTei
 ihffYAKT/tTA==
Cc:     baolu.lu@linux.intel.com, linux-kernel@vger.kernel.org,
        iommu@lists.linux-foundation.org, linuxarm@huawei.com,
        thunder.leizhen@huawei.com, chenxiang66@hisilicon.com
To:     John Garry <john.garry@huawei.com>, joro@8bytes.org,
        will@kernel.org, dwmw2@infradead.org, robin.murphy@arm.com
References: <1623414043-40745-1-git-send-email-john.garry@huawei.com>
 <1623414043-40745-3-git-send-email-john.garry@huawei.com>
From:   Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH v12 2/5] iommu: Enhance IOMMU default DMA mode build
 options
Message-ID: <a4c85f00-918b-5952-7585-8e1110ac5195@linux.intel.com>
Date:   Sat, 12 Jun 2021 09:21:59 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <1623414043-40745-3-git-send-email-john.garry@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2021/6/11 20:20, John Garry wrote:
> +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.
> +
> +	  The isolation provided in this mode is not as secure as STRICT mode,
> +	  such that a vulnerable time window may be created between the DMA
> +	  unmap and the mapping finally being torn down in the IOMMU, where the
> +	  device can still access the system memory. However this mode may

" ... and the mappings cached in the IOMMU IOTLB or device TLB finally
being invalidated, where the device probably can still access the memory
which has already been unmapped by the device driver."

Best regards,
baolu