Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp855944rdh; Thu, 23 Nov 2023 22:33:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IFuyXdJ69Ml5Ls2F8lEJlptUfpfW3Wt4QIpkB9RK9q1Vka8xqdkJWZKQQV4lMsDYeo4T1KN X-Received: by 2002:a17:90b:3811:b0:27d:882f:e6c5 with SMTP id mq17-20020a17090b381100b0027d882fe6c5mr1703042pjb.9.1700807588132; Thu, 23 Nov 2023 22:33:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700807588; cv=none; d=google.com; s=arc-20160816; b=a/iS1+oGn46aQfTIE4i95Y4WDAPqLkO6GsCw9fG7QbK4D+JAy2K2nVUm56BG3RV1D7 Z535Q4sV85/6UQ1VjixMMjIDmbkEMtnEkz3RlMMjfNhPBD/RoV63dF2xTT2LsVgeUs6G Qpl/ME/Qnwt7SHaz8WrdwXfnN5grkk3C1qeRFk6EMBn+mqH/0N8UYMpKeL/Bsu6N/LWy gwTcHMtDKnWKHVhZfLKkOCTZUZkwxK+jTD/wKdOjmAoO2tEYP8jLRty/F7Omz8fhxjBF 3IlYHBUv64eA8BA7jKsnOv6r9cmcuoxzEH+tAj9fjt1w+cJ8QMDg4luACLm4XFFhLCVt 5AoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=nXT4hsPucIdGhHn+pec7nXQcwb/WVZrBJtEzDprLOrc=; fh=kcq9QBGjSy3kNQdwaIMRYPfQKABrCunuUH1vdFJ+k7g=; b=q4h4jf7igeIBIMmOolwyOt2wmC2300ANWHc/+Bln6igo42nj18HoUx2f3cD4q+4MLh f+X1O/h+9s6fsxS+/i0KpR6YNYoiUl+TW5l16/LAMqyOvcqjcTuigpCFWVpcpYNVQc1Z ftVVhUhMn9wDwKxvCzQI5++SHODB92C1DPV6jlYslxuHBvj/ggPMprk7bN5N43kDeck7 0qpvBHhRfBKnl12UaVnnLnmAJ/J80I+sKEeoYqrT547MJiyQ9aAfW2vuuxdT4i/wxo4d 9YGNpOFsrusKXdtMw6dLwIoc6adybv8G+LuXyn65FfXOnNfQiB/vIznsFZFM0ES1Qtm6 8IgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id bb23-20020a17090b009700b00282ecb475b6si2889096pjb.174.2023.11.23.22.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 22:33:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 87D6480930F0; Thu, 23 Nov 2023 22:33:04 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229705AbjKXGaY (ORCPT + 99 others); Fri, 24 Nov 2023 01:30:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbjKXGaW (ORCPT ); Fri, 24 Nov 2023 01:30:22 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FE81AD; Thu, 23 Nov 2023 22:30:27 -0800 (PST) Received: from kwepemm000005.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Sc4jb3kDBzMnNt; Fri, 24 Nov 2023 14:25:39 +0800 (CST) Received: from [10.67.121.110] (10.67.121.110) by kwepemm000005.china.huawei.com (7.193.23.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 24 Nov 2023 14:30:24 +0800 Subject: Re: [PATCH v7 00/12] iommu: Prepare to deliver page faults to user space To: Lu Baolu , Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen CC: Yi Liu , Jacob Pan , Yan Zhao , , , References: <20231115030226.16700-1-baolu.lu@linux.intel.com> From: liulongfang Message-ID: <1a029033-3c9e-aeab-06bf-1e7020c2bc7d@huawei.com> Date: Fri, 24 Nov 2023 14:30:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20231115030226.16700-1-baolu.lu@linux.intel.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.110] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm000005.china.huawei.com (7.193.23.27) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-3.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 23 Nov 2023 22:33:04 -0800 (PST) On 2023/11/15 11:02, Lu Baolu Wrote: > When a user-managed page table is attached to an IOMMU, it is necessary > to deliver IO page faults to user space so that they can be handled > appropriately. One use case for this is nested translation, which is > currently being discussed in the mailing list. > > I have posted a RFC series [1] that describes the implementation of > delivering page faults to user space through IOMMUFD. This series has > received several comments on the IOMMU refactoring, which I am trying to > address in this series. > > The major refactoring includes: > > - [PATCH 01 ~ 04] Move include/uapi/linux/iommu.h to > include/linux/iommu.h. Remove the unrecoverable fault data definition. > - [PATCH 05 ~ 06] Remove iommu_[un]register_device_fault_handler(). > - [PATCH 07 ~ 10] Separate SVA and IOPF. Make IOPF a generic page fault > handling framework. > - [PATCH 11 ~ 12] Improve iopf framework for iommufd use. > > This is also available at github [2]. > > [1] https://lore.kernel.org/linux-iommu/20230530053724.232765-1-baolu.lu@linux.intel.com/ > [2] https://github.com/LuBaolu/intel-iommu/commits/preparatory-io-pgfault-delivery-v7 > > Change log: > v7: > - Rebase to v6.7-rc1. > - Export iopf_group_response() for global use. > - Release lock when calling iopf handler. > - The whole series has been verified to work for SVA case on Intel > platforms by Zhao Yan. Add her Tested-by to affected patches. > > v6: https://lore.kernel.org/linux-iommu/20230928042734.16134-1-baolu.lu@linux.intel.com/ > - [PATCH 09/12] Check IS_ERR() against the iommu domain. [Jingqi/Jason] > - [PATCH 12/12] Rename the comments and name of iopf_queue_flush_dev(), > no functionality changes. [Kevin] > - All patches rebased on the latest iommu/core branch. > > v5: https://lore.kernel.org/linux-iommu/20230914085638.17307-1-baolu.lu@linux.intel.com/ > - Consolidate per-device fault data management. (New patch 11) > - Improve iopf_queue_flush_dev(). (New patch 12) > > v4: https://lore.kernel.org/linux-iommu/20230825023026.132919-1-baolu.lu@linux.intel.com/ > - Merge iommu_fault_event and iopf_fault. They are duplicate. > - Move iommu_report_device_fault() and iommu_page_response() to > io-pgfault.c. > - Move iommu_sva_domain_alloc() to iommu-sva.c. > - Add group->domain and use it directly in sva fault handler. > - Misc code refactoring and refining. > > v3: https://lore.kernel.org/linux-iommu/20230817234047.195194-1-baolu.lu@linux.intel.com/ > - Convert the fault data structures from uAPI to kAPI. > - Merge iopf_device_param into iommu_fault_param. > - Add debugging on domain lifetime for iopf. > - Remove patch "iommu: Change the return value of dev_iommu_get()". > - Remove patch "iommu: Add helper to set iopf handler for domain". > - Misc code refactoring and refining. > > v2: https://lore.kernel.org/linux-iommu/20230727054837.147050-1-baolu.lu@linux.intel.com/ > - Remove unrecoverable fault data definition as suggested by Kevin. > - Drop the per-device fault cookie code considering that doesn't make > much sense for SVA. > - Make the IOMMU page fault handling framework generic. So that it can > available for use cases other than SVA. > > v1: https://lore.kernel.org/linux-iommu/20230711010642.19707-1-baolu.lu@linux.intel.com/ > > Lu Baolu (12): > iommu: Move iommu fault data to linux/iommu.h > iommu/arm-smmu-v3: Remove unrecoverable faults reporting > iommu: Remove unrecoverable fault data > iommu: Cleanup iopf data structure definitions > iommu: Merge iopf_device_param into iommu_fault_param > iommu: Remove iommu_[un]register_device_fault_handler() > iommu: Merge iommu_fault_event and iopf_fault > iommu: Prepare for separating SVA and IOPF > iommu: Make iommu_queue_iopf() more generic > iommu: Separate SVA and IOPF > iommu: Consolidate per-device fault data management > iommu: Improve iopf_queue_flush_dev() > > include/linux/iommu.h | 266 +++++++--- > drivers/iommu/intel/iommu.h | 2 +- > drivers/iommu/iommu-sva.h | 71 --- > include/uapi/linux/iommu.h | 161 ------ > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 14 +- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 51 +- > drivers/iommu/intel/iommu.c | 25 +- > drivers/iommu/intel/svm.c | 8 +- > drivers/iommu/io-pgfault.c | 469 ++++++++++++------ > drivers/iommu/iommu-sva.c | 66 ++- > drivers/iommu/iommu.c | 232 --------- > MAINTAINERS | 1 - > drivers/iommu/Kconfig | 4 + > drivers/iommu/Makefile | 3 +- > drivers/iommu/intel/Kconfig | 1 + > 15 files changed, 601 insertions(+), 773 deletions(-) > delete mode 100644 drivers/iommu/iommu-sva.h > delete mode 100644 include/uapi/linux/iommu.h > Tested-By: Longfang Liu The Arm SVA mode based on HiSilicon crypto accelerator completed the functional test and performance test of page fault scenarios. 1. The IOMMU page fault processing function is normal. 2. Performance test on 128 core ARM platform. performance is reduced: Threads Performance 8 -0.77% 16 -1.1% 32 -0.31% 64 -0.49% 128 -0.72% 256 -1.7% 384 -4.94% 512 NA??iopf timeout?? Finally, continuing to increase the number of threads will cause iommu's page fault processing to time out(more than 4.2 seconds). This problem occurs both in the before version(kernel6.7-rc1) and in the after modification's version. Thanks. Longfang.