From patchwork Thu May 31 07:42:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leizhen \(ThunderTown\)" X-Patchwork-Id: 137334 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6278035lji; Thu, 31 May 2018 00:43:54 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJy2IsH71FZg7x2tmnCGIfjTuFadiQhGYwqcy2elkLm3mSbSX5nxsi0gul5kU0+vbvs3/cm X-Received: by 2002:a62:f909:: with SMTP id o9-v6mr5829398pfh.256.1527752633970; Thu, 31 May 2018 00:43:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527752633; cv=none; d=google.com; s=arc-20160816; b=Xi1L5m5ebmUBdG8sbtKjaF9madp0sRRsSQE+oh6kNJiE2OhHF2HEu4fFKttQsuA+iL bFg8ZXmnXTs2CRb30DheFg1fsAGaGw9/1u8+xsJtUnJhk93HPcHkI6YhlBsYWdTfmYMG Y+3ewbxUNzSGE7WWNyaI58o2oSDLI/8i4k194o+B11/Vmw/cQaSaHOKpubQZBtE0UcPi rh1Gm7LA9VGdnVf5fxmps/+UtJNbutZj83Dr8K9rMA0evGrQ8atDJ+7F4bJ5uhdzMFIr j+A3j6jce89b+1TKm7Sat8FaEX85YZcVpN+/jRUOe3s+XMKKyUznrGNSXKZyRyfDLn4i D8HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=uyWxxxBq9wkSqKd8S305pHrOTzzWm63ErNmwapyFKjY=; b=T231/IhqA2dieoyX01qpZfln6et2h8HEjmTdIafhuPZvy7I8zFpFbIfSPNFxeVuq0v 4PxH3wteOp2Vo/pc0/3Nc6WQ+5meyd+aANYIaZpztdAQGn5IyL2y8L2A+2w2cYxlJqSC aV5NbvrKUEgM/Gwv5SaCB92qgCSfgs4Z2pr1R2SjqRXykeoP8O90QFNhiUhGbA+r2nQL orHMC+vWFTp2YAWijGjcv4Q6BLwSLlpvRYO1e2GRGnOFeyPctuNPUWPppeavZRhbzJtB Sdl71VLLcPoRLQXlSBkTfiiozdc3lNHkdf/G9KTHbpbl4eNbYvPPM/GLVzt7rJBIU/zh hznQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r11-v6si28682529pgp.235.2018.05.31.00.43.53; Thu, 31 May 2018 00:43:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754110AbeEaHnv (ORCPT + 30 others); Thu, 31 May 2018 03:43:51 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:50150 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754045AbeEaHnn (ORCPT ); Thu, 31 May 2018 03:43:43 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 012161AE6168E; Thu, 31 May 2018 15:43:37 +0800 (CST) Received: from localhost (10.177.23.164) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.382.0; Thu, 31 May 2018 15:43:30 +0800 From: Zhen Lei To: Robin Murphy , Will Deacon , Matthias Brugger , Rob Clark , Joerg Roedel , linux-mediatek , linux-arm-msm , linux-arm-kernel , iommu , linux-kernel CC: Zhen Lei , Hanjun Guo , Libin , Guozhu Li , "Xinwei Hu" Subject: [PATCH 0/7] add non-strict mode support for arm-smmu-v3 Date: Thu, 31 May 2018 15:42:42 +0800 Message-ID: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com> X-Mailer: git-send-email 1.9.5.msysgit.0 MIME-Version: 1.0 X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In common, a IOMMU unmap operation follow the below steps: 1. remove the mapping in page table of the specified iova range 2. execute tlbi command to invalid the mapping which is cached in TLB 3. wait for the above tlbi operation to be finished 4. free the IOVA resource 5. free the physical memory resource This maybe a problem when unmap is very frequently, the combination of tlbi and wait operation will consume a lot of time. A feasible method is put off tlbi and iova-free operation, when accumulating to a certain number or reaching a specified time, execute only one tlbi_all command to clean up TLB, then free the backup IOVAs. Mark as non-strict mode. But it must be noted that, although the mapping has already been removed in the page table, it maybe still exist in TLB. And the freed physical memory may also be reused for others. So a attacker can persistent access to memory based on the just freed IOVA, to obtain sensible data or corrupt memory. So the VFIO should always choose the strict mode. Some may consider put off physical memory free also, that will still follow strict mode. But for the map_sg cases, the memory allocation is not controlled by IOMMU APIs, so it is not enforceable. Fortunately, Intel and AMD have already applied the non-strict mode, and put queue_iova() operation into the common file dma-iommu.c., and my work is based on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to unmap, but Intel and AMD IOMMU drivers are not. Below is the performance data of strict vs non-strict for NVMe device: Randomly Read IOPS: 146K(strict) vs 573K(non-strict) Randomly Write IOPS: 143K(strict) vs 513K(non-strict) Zhen Lei (7): iommu/dma: fix trival coding style mistake iommu/arm-smmu-v3: fix the implementation of flush_iotlb_all hook iommu: prepare for the non-strict mode support iommu/amd: make sure TLB to be flushed before IOVA freed iommu/dma: add support for non-strict mode iommu/io-pgtable-arm: add support for non-strict mode iommu/arm-smmu-v3: add support for non-strict mode drivers/iommu/amd_iommu.c | 2 +- drivers/iommu/arm-smmu-v3.c | 16 ++++++++++++--- drivers/iommu/arm-smmu.c | 2 +- drivers/iommu/dma-iommu.c | 41 ++++++++++++++++++++++++++++++-------- drivers/iommu/io-pgtable-arm-v7s.c | 6 +++--- drivers/iommu/io-pgtable-arm.c | 28 ++++++++++++++------------ drivers/iommu/io-pgtable.h | 2 +- drivers/iommu/ipmmu-vmsa.c | 2 +- drivers/iommu/msm_iommu.c | 2 +- drivers/iommu/mtk_iommu.c | 2 +- drivers/iommu/qcom_iommu.c | 2 +- include/linux/iommu.h | 5 +++++ 12 files changed, 76 insertions(+), 34 deletions(-) -- 1.8.3