Message ID | 20240207013325.95182-1-baolu.lu@linux.intel.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:168b:b0:106:860b:bbdd with SMTP id ma11csp2082803dyb; Wed, 7 Feb 2024 00:26:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IH6uGp4+sw9SObZn3j2vGxG60NFt12pls1Q8XOSx2O/eB9YGiJ2J61LuVYjX/8ttNtiv5nJ X-Received: by 2002:a05:6870:e0d2:b0:214:dc31:a7b7 with SMTP id a18-20020a056870e0d200b00214dc31a7b7mr5765204oab.53.1707294391000; Wed, 07 Feb 2024 00:26:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707294390; cv=pass; d=google.com; s=arc-20160816; b=KlJC5f6fTT4syCPr+CnLuDk5dR7SckVifPqxzLcAJydyQEu4doQ8ZV+TszWY0vgkqj iFfAdolNxZgs+GgBBFBiVhmF4cht0WYoUCP7pb/s+n9pUJAYTQIOca7JpFHgOUviXoqf HU1ldi/EuZ90HvQG1u71Ss2GhheYaytxVy9QR8AL4+AI2gOSYamJwqhshJqunoDs0AN7 1vztDIWSAu8DIoZ2VN4ZwYA3Bli0w1rAsqQT6umhMI3gi95IGznijyzDr1h65izIsVJ+ baFEB1+Q+DnpiwW9zR+A8iz0oNIRKu0PYd+d1sP+C/xdQTLFafYUgnd4FS0PnTXM8Pc2 0Hfw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=jIs+kXpWRzZKbbbOB9Ty+RsFIqzVpek3remBoC90zNk=; fh=DVbOAA16Ui9Jdrp4m1LutFXz3y3QyomHSVPldK9mQlM=; b=J+LLvpzEi4eFxl7BgjEuBuXGXNWUPl4KF3t0roIOOmUHc2dwJWx6qizo0FhHMcqn5Q WQyX6qp67XYPYIDUsfYaLetDaoytnvcbZU3MDw4QoVJj7ft0IgOMrjBQ6K1Aga3bDptI 8EeZ7maS4Zwtu9GggFAiPiz2qh4TVUZi5QEBcxRSpLYVtIekgJgZL861BLi1FcktsBNJ il6il4X1N+pBOpiNTrjw9eZcg7tsoemxXCkGcvmIOhJYXXZsqgTG+gHWqz0ibNe5/Z5M 9yLMtglw3ZrwWkfPZgYLpLadbljUPDS2NV/cA/xiULnm7nSBKK7Ve+KfnNlH2Xi3B6u5 C5XA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GnX8esHo; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Forwarded-Encrypted: i=2; AJvYcCW0LHRbci5zvXwKufRxgTWyTityjh+/6gRMYM2BQAeFoVQ9e4ktX/2EbdqpxCqVsCwW5A/Ig3LVZ8RTinb17cUTXKHoFg== Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id bo12-20020a056a02038c00b005ce06ca3538si1024676pgb.873.2024.02.07.00.26.30 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 00:26:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GnX8esHo; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-55802-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 04059B2170A for <ouuuleilei@gmail.com>; Wed, 7 Feb 2024 01:39:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2FD54EAE5; Wed, 7 Feb 2024 01:39:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="GnX8esHo" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D38ED299; Wed, 7 Feb 2024 01:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707269951; cv=none; b=QeCXJyjUdiwXe8jPsOCcMVItGT5tEaEnrrJyJqS1spatrNS1UAwKnAcIFLUZhMioNz+zCpOvQFPVUEC2Ij/8wqRYxqz7pFK+QDv/JC5OuiozcB7VrRylL5EkjtWvS+LFO+T42cGFbh9WN+yM7ZXjma6hRS/ED+1x3IlR16/jOX8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707269951; c=relaxed/simple; bh=6oaC1YUxCH9GQjn6gnonmhGsI7UoDOmJjPUCm9v5DgU=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=o1Hs7dxSX7ZVE1yTCDRhu+R8V8bRsvOnQjiN613K6wbcga6xjGYOY3aXOcndymbu3n0YCjs46ZiBb7AaMXbaV/t0WwH2l8AfBmKN4q4GvU1kkWfbw/PhAk4SDxVQ660q0z/zO9fckmp0nQu9bnX4w1uKG+sgYdbdBg+rpvTk3NA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=GnX8esHo; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707269948; x=1738805948; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=6oaC1YUxCH9GQjn6gnonmhGsI7UoDOmJjPUCm9v5DgU=; b=GnX8esHo2JnogYEanGc4UM+/kQpfi2YdjwhDhsMwh07VoEVBq7W9HQhz 553EYjRIfYZg048B9N2PTjYi7u9XNqVZYkTRn6xzsDs0VV1Y4ZapBCJFi uO/GE8WbHUxf8f2iEJlj8MUNuQSXsbT7YELWZTpexWURDudwxRNb0jUYq 7grBQAHvm+PPMUIjApGGiiDVqdbVDtBc640hsdoKdPDdPqv+gMscuGy8d d2Bq/mFEhdPGxFv8i5yRaEJmtrwoVIcqig+28AcKCcNw+WddfiOnuKw+8 FihEK0G+rv0IQIXNIUFvE+N3Zj9LokduuE+pq8ZBhKFdutvoQHgjvhOM+ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10976"; a="11533955" X-IronPort-AV: E=Sophos;i="6.05,248,1701158400"; d="scan'208";a="11533955" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2024 17:39:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,248,1701158400"; d="scan'208";a="1190525" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmviesa010.fm.intel.com with ESMTP; 06 Feb 2024 17:39:03 -0800 From: Lu Baolu <baolu.lu@linux.intel.com> To: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, Nicolin Chen <nicolinc@nvidia.com> Cc: Yi Liu <yi.l.liu@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Longfang Liu <liulongfang@huawei.com>, Yan Zhao <yan.y.zhao@intel.com>, Joel Granados <j.granados@samsung.com>, iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com> Subject: [PATCH v12 00/16] iommu: Prepare to deliver page faults to user space Date: Wed, 7 Feb 2024 09:33:09 +0800 Message-Id: <20240207013325.95182-1-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790227923606083255 X-GMAIL-MSGID: 1790227923606083255 |
Series |
iommu: Prepare to deliver page faults to user space
|
|
Message
Baolu Lu
Feb. 7, 2024, 1:33 a.m. UTC
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 ~ 16] Improve iopf framework. 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-v12 Change log: v12: - Add Jason and Kevin's Reviewed-by tags. - Fix some minor comments. - No code change. v11: https://lore.kernel.org/linux-iommu/20240130080835.58921-1-baolu.lu@linux.intel.com/ - Cleanup IOMMU_PAGE_RESP_PASID_VALID flag bit. - Cleanup code comments. v10: https://lore.kernel.org/linux-iommu/20240122054308.23901-1-baolu.lu@linux.intel.com/ - Make iopf_group_response() return void, as nobody can do anything with the failure. - Make iommu_report_device_fault() automatically respond to unhandleable faults and change its return type to void. - PATCH 01 ~ 14 are in good shapes now. v9: https://lore.kernel.org/linux-iommu/20231220012332.168188-1-baolu.lu@linux.intel.com/ - Protecting the assignment of dev->iommu->fault_param with RCU. - Extending the fault parameter's lifetime to the entire path of iopf handling. - Since iopf_queue_flush_dev() can only be called before iopf_queue_remove_device(), there's no need to hold a reference count. - Improve iopf_queue_remove_device() as per Jason's comments on the device removal sequence from the iopf queue. This will likely require changes to the iommu drivers, which are supposed to be addressed in separate series. - Track the iopf_group as a whole instead of the last fault within the group to simplify the fault report and response paths. - PATCH 01 ~ 11 are in good shapes now. v8: https://lore.kernel.org/linux-iommu/20231207064308.313316-1-baolu.lu@linux.intel.com/ - Drop PATCH 12/12 as it is no longer necessary to drain page requests page requests during PASID translation changes. - Separate PATCH 11/12 into two distinct patches. The first patch refines locking scheme for protecting per-device fault data, while the second patch replaces mutex with RCU to enhance locking efficiency. - PATCH 01 ~ 10 are in good shapes now. v7: https://lore.kernel.org/linux-iommu/20231115030226.16700-1-baolu.lu@linux.intel.com/ - 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 (16): 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: Refine locking for per-device fault data management iommu: Use refcount for fault data access iommu: Improve iopf_queue_remove_device() iommu: Track iopf group instead of last fault iommu: Make iopf_group_response() return void iommu: Make iommu_report_device_fault() return void include/linux/iommu.h | 262 +++++++--- drivers/iommu/intel/iommu.h | 4 +- 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 | 103 ++-- drivers/iommu/intel/iommu.c | 28 +- drivers/iommu/intel/svm.c | 41 +- drivers/iommu/io-pgfault.c | 473 ++++++++++-------- drivers/iommu/iommu-sva.c | 71 ++- drivers/iommu/iommu.c | 233 --------- MAINTAINERS | 1 - drivers/iommu/Kconfig | 4 + drivers/iommu/Makefile | 3 +- drivers/iommu/intel/Kconfig | 1 + 15 files changed, 583 insertions(+), 887 deletions(-) delete mode 100644 drivers/iommu/iommu-sva.h delete mode 100644 include/uapi/linux/iommu.h
Comments
On Wed, 7 Feb 2024 at 09:39, Lu Baolu <baolu.lu@linux.intel.com> 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 ~ 16] Improve iopf framework. > > 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-v12 > Wandering are these patches dropped now, [PATCH v2 2/6] iommufd: Add iommu page fault uapi data https://lore.kernel.org/lkml/20231026024930.382898-3-baolu.lu@linux.intel.com/raw [PATCH v2 4/6] iommufd: Deliver fault messages to user space https://lore.kernel.org/lkml/20231026024930.382898-5-baolu.lu@linux.intel.com/ And does iouring still be used in user space? Thanks
On 2024/2/8 17:03, Zhangfei Gao wrote: > Hi, Baolu > > On Wed, 7 Feb 2024 at 09:39, Lu Baolu <baolu.lu@linux.intel.com > <mailto:baolu.lu@linux.intel.com>> 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 ~ 16] Improve iopf framework. > > This is also available at github [2]. > > [1] > https://lore.kernel.org/linux-iommu/20230530053724.232765-1-baolu.lu@linux.intel.com/ <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-v12 <https://github.com/LuBaolu/intel-iommu/commits/preparatory-io-pgfault-delivery-v12> > > > Wandering are these patches dropped now, > > [PATCH v2 2/6] iommufd: Add iommu page fault uapi data > https://lore.kernel.org/lkml/20231026024930.382898-3-baolu.lu@linux.intel.com/raw <https://lore.kernel.org/lkml/20231026024930.382898-3-baolu.lu@linux.intel.com/raw> > > [PATCH v2 4/6] iommufd: Deliver fault messages to user space > https://lore.kernel.org/lkml/20231026024930.382898-5-baolu.lu@linux.intel.com/ <https://lore.kernel.org/lkml/20231026024930.382898-5-baolu.lu@linux.intel.com/> Above patches are part of another series named "IOMMUFD: Deliver IO page faults to user space", which is now updated to v3. https://lore.kernel.org/linux-iommu/20240122073903.24406-1-baolu.lu@linux.intel.com/ > And does iouring still be used in user space? iouring is not related to this series. For uapi of iommufd, it's still recommended to use iouring to speed up the handling of faults. Best regards, baolu