Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1034545pxf; Thu, 8 Apr 2021 20:46:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxT4YDGjthgo9SsEY2MF2JlMOenz/wRyNjLVYy4LFRhko34Z07Bs4t9VFP+C6jcJ6WzQjv X-Received: by 2002:a05:6402:1759:: with SMTP id v25mr15390930edx.177.1617940014359; Thu, 08 Apr 2021 20:46:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617940014; cv=none; d=google.com; s=arc-20160816; b=cTYEWRiEw+6mRoDtjqDoss3UJTO/BbX6Xo005g0cjbo16ZcuEQQfJGLZSZKWnPR//Y GKFg8o0O8UXXzc9X6JoAcTaw+RncPz/aubuuNEfCNH46Zm73JXWq8B0wYcBpqWlP/9Zk pCyGGyq84Vb89qG8GzeZ3bzHFbs0Pn1IAQtWwWh92lt1zd8QGG9Kgzw8HququNpdyQSU UElVCa+3VNnTAq41sMGTabxiHv45RzSz3PYf0jY2BZgquFACPZaSlg+wbUYMd9McbxRL 0+cOji+j4IYVn3XFNucfY/E3QggiAfVzfcOxpxKr8RTwaUR+QTpI0Ug/b0TssuC76vk8 qsVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=aST2/ilp79u7GhClfJCJF903Y2FYb8N9kdVlXTMhYrg=; b=LTX9MhYYW29zT4yp8/OryNzWzdnJLmHjD85uFZG3HTa+mKSXmR0BOmX0twBUkV3N4t DmtYbibHH2uJZTzAZ3nMd3wl5i51y9i8b81eupk4l3OYxH+0+N4RmzezmoTUIqLBjb/U bXbIJzEE42+BWmgrANe80MuThn6DGtp+kFSUaUMQGwmiYzb8CBD9v1wj8sb+SoKNJ7RY qrTOjap/+A3qg6IHm2bew7E4u3SDr2Bvz3D74dN/MyNE06Vtv3MYlNd3Uz6WjC86iebK PQZ4aSgj9CKSxfEqIhl7R1pKS7Lv4yzeDjG81bU0oasCWN2qaYHovr5P1DWRJuc0Dyj/ O5xA== 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 n11si1276769edi.36.2021.04.08.20.46.31; Thu, 08 Apr 2021 20:46:54 -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 S233256AbhDIDo5 (ORCPT + 99 others); Thu, 8 Apr 2021 23:44:57 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:15637 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232662AbhDIDoz (ORCPT ); Thu, 8 Apr 2021 23:44:55 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FGkTF20x7znZ7c; Fri, 9 Apr 2021 11:41:53 +0800 (CST) Received: from DESKTOP-7FEPK9S.china.huawei.com (10.174.184.135) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Fri, 9 Apr 2021 11:44:30 +0800 From: Shenming Lu To: Alex Williamson , Cornelia Huck , Will Deacon , Robin Murphy , Joerg Roedel , Jean-Philippe Brucker , Eric Auger , , , , , CC: Kevin Tian , Lu Baolu , , Christoph Hellwig , Jonathan Cameron , Barry Song , , , Subject: [RFC PATCH v3 0/8] Add IOPF support for VFIO passthrough Date: Fri, 9 Apr 2021 11:44:12 +0800 Message-ID: <20210409034420.1799-1-lushenming@huawei.com> X-Mailer: git-send-email 2.27.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.174.184.135] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Requesting for your comments and suggestions. :-) The static pinning and mapping problem in VFIO and possible solutions have been discussed a lot [1, 2]. One of the solutions is to add I/O Page Fault support for VFIO devices. Different from those relatively complicated software approaches such as presenting a vIOMMU that provides the DMA buffer information (might include para-virtualized optimizations), IOPF mainly depends on the hardware faulting capability, such as the PCIe PRI extension or Arm SMMU stall model. What's more, the IOPF support in the IOMMU driver has already been implemented in SVA [3]. So we add IOPF support for VFIO passthrough based on the IOPF part of SVA in this series. We have measured its performance with UADK [4] (passthrough an accelerator to a VM(1U16G)) on Hisilicon Kunpeng920 board (and compared with host SVA): Run hisi_sec_test... - with varying sending times and message lengths - with/without IOPF enabled (speed slowdown) when msg_len = 1MB (and PREMAP_LEN (in Patch 4) = 1): slowdown (num of faults) times VFIO IOPF host SVA 1 63.4% (518) 82.8% (512) 100 22.9% (1058) 47.9% (1024) 1000 2.6% (1071) 8.5% (1024) when msg_len = 10MB (and PREMAP_LEN = 512): slowdown (num of faults) times VFIO IOPF 1 32.6% (13) 100 3.5% (26) 1000 1.6% (26) History: v2 -> v3 - Nit fixes. - No reason to disable reporting the unrecoverable faults. (baolu) - Maintain a global IOPF enabled group list. - Split the pre-mapping optimization to be a separate patch. - Add selective faulting support (use vfio_pin_pages to indicate the non-faultable scope and add a new struct vfio_range to record it, untested). (Kevin) v1 -> v2 - Numerous improvements following the suggestions. Thanks a lot to all of you. Note that PRI is not supported at the moment since there is no hardware. Links: [1] Lesokhin I, et al. Page Fault Support for Network Controllers. In ASPLOS, 2016. [2] Tian K, et al. coIOMMU: A Virtual IOMMU with Cooperative DMA Buffer Tracking for Efficient Memory Management in Direct I/O. In USENIX ATC, 2020. [3] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210401154718.307519-1-jean-philippe@linaro.org/ [4] https://github.com/Linaro/uadk Thanks, Shenming Shenming Lu (8): iommu: Evolve the device fault reporting framework vfio/type1: Add a page fault handler vfio/type1: Add an MMU notifier to avoid pinning vfio/type1: Pre-map more pages than requested in the IOPF handling vfio/type1: VFIO_IOMMU_ENABLE_IOPF vfio/type1: No need to statically pin and map if IOPF enabled vfio/type1: Add selective DMA faulting support vfio: Add nested IOPF support .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 3 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 +- drivers/iommu/iommu.c | 56 +- drivers/vfio/vfio.c | 85 +- drivers/vfio/vfio_iommu_type1.c | 1000 ++++++++++++++++- include/linux/iommu.h | 19 +- include/linux/vfio.h | 13 + include/uapi/linux/iommu.h | 4 + include/uapi/linux/vfio.h | 6 + 9 files changed, 1181 insertions(+), 23 deletions(-) -- 2.19.1