Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp1035978rdh; Fri, 24 Nov 2023 04:03:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IGxj1CqQG20TQVIpatZkk1L6Lk9evbacYHFCzR+VktBnEN/oZj+9jHSELEqU6k2okBAZlvL X-Received: by 2002:a05:6830:154b:b0:6d6:4697:6a91 with SMTP id l11-20020a056830154b00b006d646976a91mr2675907otp.13.1700827418271; Fri, 24 Nov 2023 04:03:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700827418; cv=none; d=google.com; s=arc-20160816; b=JT2jQQ1B1L0T/YRht8orbcUwxVg8VXi2tSOGlGBNhyjpKz8dnrsaE3BHNGGRhwX7iU c6loTBmGNyHcBV+IxIlP9AsbWZR8aiYbFiQkEL32YGehQOiIz3jxV8kXJYs7VEF37m2m AmpqtK+xF2qaLuxmNwfW0cIwYHnUCnrmQ51LoiNxiJAxM1fo/S98j3EB0BWy5U1zrPOV DTNNy4egj391oi22MOunb1CLnWaScpIGziTTqv3Hj7x3s6dTBK831TWAHhlHq4QJCVdo 20OUtT8/JxM+C012AUhtbPaZ99U7hCDiLofwXXRurmcYPC19QL05JotW5MWuGoTQedjS zRYw== 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:from :content-language:references:to:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=/KeKse0xLeACbWYRxJTLamzsjJOlQP1fq5VIijLQ+cs=; fh=AXQLxmDwU73HTaBCEpooe414/G5oYSYVRp8j/NsNKp0=; b=y8dtCZLLerShpvN+nSItvjnaecu/3TqZL2oMNI3dV29MlwkK5nw/JesDsvvUNuiya+ kRd8IIBa/Po4UtniTleg/bw9n+Lzk1TfquWeUyFrt5qE0EgihknsN04FJLTysUFr+YKl RPOJ+uEgeubWxGOKdH93LdM9sAu96ZgyFZtv84GKXLmfP5QIQ7XCkOpktHqp3taj2BxD qKxYBEmnMle062COpyf/5yIihWI+IxGvwRwZV9zuUsbFD3Jr+2VZg02jIYyJHjeRhnmQ I/6Fo5WOpCQv28BULlMtQltTpD3hsCfTRBrHetgGx1yd6C5rc3quP2Dkj862XaxbAV+O LB2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Uj0oenYz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id c7-20020a056830000700b006d312230086si1179343otp.310.2023.11.24.04.03.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Nov 2023 04:03:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Uj0oenYz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 465F3807A591; Fri, 24 Nov 2023 04:02:09 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230104AbjKXMBr (ORCPT + 99 others); Fri, 24 Nov 2023 07:01:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbjKXMBq (ORCPT ); Fri, 24 Nov 2023 07:01:46 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C79410CB; Fri, 24 Nov 2023 04:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1700827312; x=1732363312; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=vnwBM3tljMEcetDptjzZqGvpgTMc7X/b1g4fgPwK904=; b=Uj0oenYzTYiL9qG9CwElg20KuwOHnXMOXWFtWVjVrBoIdMDJafJXrwMI 4pOaP4o4A2ET155mlCNltecOPRsUb7gO2rvscRWGrefCvh0lsiFG8A9T2 OMON5UNZ7sJMSZajn37Vu9QuvVqBvHnnVcumvSsghrsZRGjENWIbKbCcg KoWWIqI6WQzQOElvGj9Psi9gR4UOD6z0Y8x5C84z4aaRpugtIfmzandOv IV8aZhqSpjskZSDvXmFYAO9V0mfz9SRntziEQnH4c3LOh+u9yyoiTTjC4 wxCUsWP0NwWcr/6IB5dhvffb7dS50X9yURf35Rt2PPMczQg+Rzn4L3MNR A==; X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="13967944" X-IronPort-AV: E=Sophos;i="6.04,224,1695711600"; d="scan'208";a="13967944" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2023 04:01:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10902"; a="838068621" X-IronPort-AV: E=Sophos;i="6.04,224,1695711600"; d="scan'208";a="838068621" Received: from moqiongz-mobl.ccr.corp.intel.com (HELO [10.255.28.60]) ([10.255.28.60]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2023 04:01:47 -0800 Message-ID: <7a683525-07ca-4ff1-97bd-0193d07dc857@linux.intel.com> Date: Fri, 24 Nov 2023 20:01:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Yi Liu , Jacob Pan , Yan Zhao , iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 00/12] iommu: Prepare to deliver page faults to user space To: liulongfang , Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen References: <20231115030226.16700-1-baolu.lu@linux.intel.com> <1a029033-3c9e-aeab-06bf-1e7020c2bc7d@huawei.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <1a029033-3c9e-aeab-06bf-1e7020c2bc7d@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 agentk.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 (agentk.vger.email [0.0.0.0]); Fri, 24 Nov 2023 04:02:09 -0800 (PST) On 2023/11/24 14:30, liulongfang wrote: > 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 Thank you for the testing. > > 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. Probably you can check whether commit 6bbd42e2df8f ("mmu_notifiers: call invalidate_range() when invalidating TLBs") matters. It was discussed in this thread. https://lore.kernel.org/linux-iommu/20231117090933.75267-1-baolu.lu@linux.intel.com/ Best regards, baolu