All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: iommu@lists.linux.dev, linux-kselftest@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com>
Subject: [PATCH v2 2/6] iommufd: Add iommu page fault uapi data
Date: Thu, 26 Oct 2023 10:49:26 +0800	[thread overview]
Message-ID: <20231026024930.382898-3-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20231026024930.382898-1-baolu.lu@linux.intel.com>

For user to handle IO page faults generated by IOMMU hardware when
walking the HWPT managed by the user. One example of the use case
is nested translation, where the first-stage page table is managed
by the user space.

When allocating a user HWPT, the user could opt-in a flag named
IOMMU_HWPT_ALLOC_IOPF_CAPABLE, which indicates that user is capable
of handling IO page faults generated for this HWPT.

On a successful return of hwpt allocation, the user can retrieve
and respond the page faults by reading and writing the fd returned
in out_fault_fd. The format of the page fault and response data is
encoded in the format defined by struct iommu_hwpt_pgfault and
struct iommu_hwpt_response.

The iommu_hwpt_pgfault is mostly like the iommu_fault with some new
members like fault data size and the device object id where the page
fault was originated from.

Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 include/uapi/linux/iommufd.h | 65 ++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index f9b8b95b36b2..0f00f1dfcded 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -355,9 +355,17 @@ struct iommu_vfio_ioas {
  * @IOMMU_HWPT_ALLOC_NEST_PARENT: If set, allocate a domain which can serve
  *                                as the parent domain in the nesting
  *                                configuration.
+ * @IOMMU_HWPT_ALLOC_IOPF_CAPABLE: User is capable of handling IO page faults.
+ *                                 On successful return, user can retrieve
+ *                                 faults by reading the @out_fault_fd and
+ *                                 respond the faults by writing it. The fault
+ *                                 data is encoded in the format defined by
+ *                                 iommu_hwpt_pgfault. The response data format
+ *                                 is defined by iommu_hwpt_page_response
  */
 enum iommufd_hwpt_alloc_flags {
 	IOMMU_HWPT_ALLOC_NEST_PARENT = 1 << 0,
+	IOMMU_HWPT_ALLOC_IOPF_CAPABLE = 1 << 1,
 };
 
 /**
@@ -476,6 +484,7 @@ struct iommu_hwpt_alloc {
 	__u32 hwpt_type;
 	__u32 data_len;
 	__aligned_u64 data_uptr;
+	__u32 out_fault_fd;
 };
 #define IOMMU_HWPT_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_ALLOC)
 
@@ -679,6 +688,62 @@ struct iommu_dev_data_arm_smmuv3 {
 	__u32 sid;
 };
 
+/**
+ * struct iommu_hwpt_pgfault - iommu page fault data
+ * @size: sizeof(struct iommu_hwpt_pgfault)
+ * @flags: Combination of IOMMU_PGFAULT_FLAGS_ flags.
+ *  - PASID_VALID: @pasid field is valid
+ *  - LAST_PAGE: the last page fault in a group
+ *  - PRIV_DATA: @private_data field is valid
+ *  - RESP_NEEDS_PASID: the page response must have the same
+ *                      PASID value as the page request.
+ * @dev_id: id of the originated device
+ * @pasid: Process Address Space ID
+ * @grpid: Page Request Group Index
+ * @perm: requested page permissions (IOMMU_PGFAULT_PERM_* values)
+ * @addr: page address
+ * @private_data: device-specific private information
+ */
+struct iommu_hwpt_pgfault {
+	__u32 size;
+	__u32 flags;
+#define IOMMU_PGFAULT_FLAGS_PASID_VALID		(1 << 0)
+#define IOMMU_PGFAULT_FLAGS_LAST_PAGE		(1 << 1)
+#define IOMMU_PGFAULT_FLAGS_PRIV_DATA		(1 << 2)
+#define IOMMU_PGFAULT_FLAGS_RESP_NEEDS_PASID	(1 << 3)
+	__u32 dev_id;
+	__u32 pasid;
+	__u32 grpid;
+	__u32 perm;
+#define IOMMU_PGFAULT_PERM_READ			(1 << 0)
+#define IOMMU_PGFAULT_PERM_WRITE		(1 << 1)
+#define IOMMU_PGFAULT_PERM_EXEC			(1 << 2)
+#define IOMMU_PGFAULT_PERM_PRIV			(1 << 3)
+	__u64 addr;
+	__u64 private_data[2];
+};
+
+/**
+ * struct iommu_hwpt_response - IOMMU page fault response
+ * @size: sizeof(struct iommu_hwpt_response)
+ * @flags: Must be set to 0
+ * @hwpt_id: hwpt ID of target hardware page table for the response
+ * @dev_id: device ID of target device for the response
+ * @pasid: Process Address Space ID
+ * @grpid: Page Request Group Index
+ * @code: response code. The supported codes include:
+ *        0: Successful; 1: Response Failure; 2: Invalid Request.
+ */
+struct iommu_hwpt_page_response {
+	__u32 size;
+	__u32 flags;
+	__u32 hwpt_id;
+	__u32 dev_id;
+	__u32 pasid;
+	__u32 grpid;
+	__u32 code;
+};
+
 /**
  * struct iommu_set_dev_data - ioctl(IOMMU_SET_DEV_DATA)
  * @size: sizeof(struct iommu_set_dev_data)
-- 
2.34.1


  parent reply	other threads:[~2023-10-26  2:53 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26  2:49 [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space Lu Baolu
2023-10-26  2:49 ` [PATCH v2 1/6] iommu: Add iommu page fault cookie helpers Lu Baolu
2023-12-01 14:38   ` Jason Gunthorpe
2023-12-08  6:24     ` Baolu Lu
2023-10-26  2:49 ` Lu Baolu [this message]
2023-12-01 15:14   ` [PATCH v2 2/6] iommufd: Add iommu page fault uapi data Jason Gunthorpe
2023-12-08  6:35     ` Baolu Lu
2023-10-26  2:49 ` [PATCH v2 3/6] iommufd: Initializing and releasing IO page fault data Lu Baolu
     [not found]   ` <CGME20231212131010eucas1p104d069ac6d6c97fce4987caa62c996ee@eucas1p1.samsung.com>
2023-12-12 13:10     ` Joel Granados
2023-12-12 14:12       ` Jason Gunthorpe
2023-12-13  2:04         ` Baolu Lu
2023-12-13  2:15           ` Tian, Kevin
2023-12-13 13:19             ` Jason Gunthorpe
2023-10-26  2:49 ` [PATCH v2 4/6] iommufd: Deliver fault messages to user space Lu Baolu
2023-12-01 15:24   ` Jason Gunthorpe
2023-12-08 11:43     ` Baolu Lu
     [not found]   ` <CGME20231207163412eucas1p2fa912b4923031804c27c764e5c8d67e7@eucas1p2.samsung.com>
2023-12-07 16:34     ` Joel Granados
2023-12-07 17:17       ` Jason Gunthorpe
2023-12-08  5:47         ` Baolu Lu
2023-12-08 13:41           ` Jason Gunthorpe
2024-01-12 17:46   ` Shameerali Kolothum Thodi
2024-01-15 16:47     ` Jason Gunthorpe
2024-01-15 17:44       ` Shameerali Kolothum Thodi
2024-01-15 17:58         ` Jason Gunthorpe
2023-10-26  2:49 ` [PATCH v2 5/6] iommufd/selftest: Add IOMMU_TEST_OP_TRIGGER_IOPF test support Lu Baolu
2023-10-26  2:49 ` [PATCH v2 6/6] iommufd/selftest: Add coverage for IOMMU_TEST_OP_TRIGGER_IOPF Lu Baolu
2023-11-02 12:47 ` [PATCH v2 0/6] IOMMUFD: Deliver IO page faults to user space Jason Gunthorpe
2023-11-02 12:47   ` Jason Gunthorpe
2023-11-07  8:35   ` Tian, Kevin
2023-11-07  8:35     ` Tian, Kevin
2023-11-07 17:54     ` Jason Gunthorpe
2023-11-07 17:54       ` Jason Gunthorpe
2023-11-08  8:53       ` Tian, Kevin
2023-11-08 17:39         ` Jason Gunthorpe
     [not found]   ` <c774e157-9b47-4fb8-80dd-37441c69b43d@linux.intel.com>
2023-11-15 13:58     ` Jason Gunthorpe
2023-11-16  1:42       ` Liu, Jing2
2023-11-21  0:14         ` Jason Gunthorpe
2023-11-29  9:08 ` Shameerali Kolothum Thodi
2023-11-30  3:44   ` Baolu Lu
2023-12-01 14:24 ` Jason Gunthorpe
2023-12-08  5:57   ` Baolu Lu
2023-12-08 13:43     ` Jason Gunthorpe
     [not found] ` <CGME20231204150747eucas1p2365e92a7ac33ba99b801d7c800acaf6a@eucas1p2.samsung.com>
2023-12-04 15:07   ` Joel Granados
2023-12-04 15:32     ` Jason Gunthorpe
2023-12-08  5:10     ` Baolu Lu
     [not found] ` <CGME20240112215609eucas1p1eedeeee8e1cca2c935b41816a50f56f6@eucas1p1.samsung.com>
2024-01-12 21:56   ` Joel Granados
2024-01-14 13:13     ` Baolu Lu
2024-01-14 17:18       ` Joel Granados
2024-01-15  1:25         ` Baolu Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231026024930.382898-3-baolu.lu@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.