Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1331064imm; Wed, 11 Jul 2018 23:20:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpccVuMexJFCNudRhyz4qI8yMOE/pnPk4ZV2Lyoir5jKgcfv6337t6oaCLGokRliT+66mnPD X-Received: by 2002:a17:902:a613:: with SMTP id u19-v6mr908335plq.234.1531376414090; Wed, 11 Jul 2018 23:20:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531376414; cv=none; d=google.com; s=arc-20160816; b=dXcAXnv/dQcwrqFb6leDYhINR/qLuFmWg84Yc3PuNrVOldRXFqHzshAHKVyeDgGmg7 oqA6NFIKanTZ+KVFIzKELC1aJV/c8yxkpExxuingSv0d07GgcvbsQxnXQWRxi5OZlfAk ktjvLfDXXg2OnSlyHCJYEtwO88XJNwIHzArI7mnXxBEfyrreEVmhv9uaUy1eJVn0hQRG jpZVOPISl2/B+cBt9qz/wK02VHiGZd8qm8BNw8cW53Vbr+8lWwt3sTKWQIojb/4vsJib txWqAt6wBoUsPPXopqo70lxCSXd+PhzDJzzG1hch4qKBdBtMOSsDzSsv4Ph70TdiCYIt tUgQ== 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=D+kMejQkkImbWwo/+c4z522IlF8UdTyMpsGfY3JKuec=; b=dGzvCpWVX7CzNmNw6tUPT21E+Q1Ah7oqSgvS43YUFsr2GG34jcp9z99Ow3nwVTPWil Q/aAA1qDXpzlEAQUAF6vxyFeqt3L0CGR1Nm1UTU7XpDz2WQNL2W+EKeulTC+uyc2JnXK fwBYbK0EGyd3HaehqK72nJh3tn/L38RYjCgCJKXNyjuQwAasGslaNzxXRRZY4TXZjdyO F1iE7XBTyzblgr8L18c+mIqQxCHV8MF5HtUQXO73Xw8R4qhJMfGlV/wTrzksik6D8WjF X+NynHWLybb08Cv9p8joTd3FwWkheqJpjw4Upz8rF0GW15mGAfHQhCGYr8H2I628ISd6 8aMw== 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 o184-v6si15684962pfb.78.2018.07.11.23.19.58; Wed, 11 Jul 2018 23:20:14 -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 S1732368AbeGLG1Y (ORCPT + 99 others); Thu, 12 Jul 2018 02:27:24 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:9173 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726584AbeGLG1Y (ORCPT ); Thu, 12 Jul 2018 02:27:24 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id E1307381B60DA; Thu, 12 Jul 2018 14:19:04 +0800 (CST) Received: from localhost (10.177.23.164) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.382.0; Thu, 12 Jul 2018 14:18:58 +0800 From: Zhen Lei To: Jean-Philippe Brucker , Robin Murphy , Will Deacon , Joerg Roedel , linux-arm-kernel , iommu , linux-kernel CC: Zhen Lei Subject: [PATCH v3 0/6] add non-strict mode support for arm-smmu-v3 Date: Thu, 12 Jul 2018 14:18:26 +0800 Message-ID: <1531376312-2192-1-git-send-email-thunder.leizhen@huawei.com> X-Mailer: git-send-email 1.9.5.msysgit.0 MIME-Version: 1.0 Content-Type: text/plain 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 v2 -> v3: Add a bootup option "iommu_strict_mode" to make the manager can choose which mode to be used. The first 5 patches have not changed. + iommu_strict_mode= [arm-smmu-v3] + 0 - strict mode (default) + 1 - non-strict mode v1 -> v2: Use the lowest bit of the io_pgtable_ops.unmap's iova parameter to pass the strict mode: 0, IOMMU_STRICT; 1, IOMMU_NON_STRICT; Treat 0 as IOMMU_STRICT, so that the unmap operation can compatible with other IOMMUs which still use strict mode. In other words, this patch series will not impact other IOMMU drivers. I tried add a new quirk IO_PGTABLE_QUIRK_NON_STRICT in io_pgtable_cfg.quirks, but it can not pass the strict mode of the domain from SMMUv3 driver to io-pgtable module. Add a new member domain_non_strict in struct iommu_dma_cookie, this member will only be initialized when the related domain and IOMMU driver support non-strict mode. v1: 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 (6): iommu/arm-smmu-v3: fix the implementation of flush_iotlb_all hook iommu/dma: add support for non-strict mode iommu/amd: use default branch to deal with all non-supported capabilities iommu/io-pgtable-arm: add support for non-strict mode iommu/arm-smmu-v3: add support for non-strict mode iommu/arm-smmu-v3: add bootup option "iommu_strict_mode" Documentation/admin-guide/kernel-parameters.txt | 12 +++++++ drivers/iommu/amd_iommu.c | 4 +-- drivers/iommu/arm-smmu-v3.c | 42 +++++++++++++++++++++++-- drivers/iommu/dma-iommu.c | 25 +++++++++++++++ drivers/iommu/io-pgtable-arm.c | 23 ++++++++------ include/linux/iommu.h | 7 +++++ 6 files changed, 98 insertions(+), 15 deletions(-) -- 1.8.3