iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: joro@8bytes.org, alex.williamson@redhat.com, jgg@nvidia.com,
	kevin.tian@intel.com, robin.murphy@arm.com,
	baolu.lu@linux.intel.com
Cc: cohuck@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com,
	kvm@vger.kernel.org, mjrosato@linux.ibm.com,
	chao.p.peng@linux.intel.com, yi.l.liu@intel.com,
	yi.y.sun@linux.intel.com, peterx@redhat.com, jasowang@redhat.com,
	shameerali.kolothum.thodi@huawei.com, lulu@redhat.com,
	suravee.suthikulpanit@amd.com, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	zhenzhong.duan@intel.com
Subject: [PATCH v2 01/11] iommu: Add new iommu op to create domains owned by userspace
Date: Thu, 11 May 2023 07:38:34 -0700	[thread overview]
Message-ID: <20230511143844.22693-2-yi.l.liu@intel.com> (raw)
In-Reply-To: <20230511143844.22693-1-yi.l.liu@intel.com>

From: Lu Baolu <baolu.lu@linux.intel.com>

Introduce a new iommu_domain op to create domains owned by userspace,
e.g. through iommufd. These domains have a few different properties
compares to kernel owned domains:

 - They may be UNMANAGED domains, but created with special parameters.
   For instance aperture size changes/number of levels, different
   IOPTE formats, or other things necessary to make a vIOMMU work

 - We have to track all the memory allocations with GFP_KERNEL_ACCOUNT
   to make the cgroup sandbox stronger

 - Device-specialty domains, such as NESTED domains can be created by
   iommufd.

The new op clearly says the domain is being created by IOMMUFD, that
the domain is intended for userspace use, and it provides a way to pass
a driver specific uAPI structure to customize the created domain to
exactly what the vIOMMU userspace driver requires.

iommu drivers that cannot support VFIO/IOMMUFD should not support this
op. This includes any driver that cannot provide a fully functional
UNMANAGED domain.

This op chooses to make the special parameters opaque to the core. This
suits the current usage model where accessing any of the IOMMU device
special parameters does require a userspace driver that matches the
kernel driver. If a need for common parameters, implemented similarly
by several drivers, arises then there is room in the design to grow a
generic parameter set as well.

This new op for now is only supposed to be used by iommufd, hence no
wrapper for it. iommufd would call the callback directly. As for domain
free, iommufd would use iommu_domain_free().

Also, add an op to return the length of supported user data structures
that must be added to include/uapi/include/iommufd.h file. This helps
the iommufd core to sanitize the input data before it forwards the data
to an iommu driver.

Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Co-developed-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Yi Liu <yi.l.liu@intel.com>
---
 include/linux/iommu.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a748d60206e7..7f2046fa53a3 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -220,6 +220,15 @@ struct iommu_iotlb_gather {
 	bool			queued;
 };
 
+/*
+ * The user data to allocate a specific type user iommu domain
+ *
+ * This includes the corresponding driver data structures in
+ * include/uapi/linux/iommufd.h.
+ */
+union iommu_domain_user_data {
+};
+
 /**
  * struct iommu_ops - iommu ops and capabilities
  * @capable: check capability
@@ -229,6 +238,15 @@ struct iommu_iotlb_gather {
  *           after use. Return the data buffer if success, or ERR_PTR on
  *           failure.
  * @domain_alloc: allocate iommu domain
+ * @domain_alloc_user: allocate user iommu domain
+ * @domain_alloc_user_data_len: return the required length of the user data
+ *                              to allocate a specific type user iommu domain.
+ *                              @hwpt_type is defined as enum iommu_hwpt_type
+ *                              in include/uapi/linux/iommufd.h. The returned
+ *                              length is the corresponding sizeof driver data
+ *                              structures in include/uapi/linux/iommufd.h.
+ *                              -EOPNOTSUPP would be returned if the input
+ *                              @hwpt_type is not supported by the driver.
  * @probe_device: Add device to iommu driver handling
  * @release_device: Remove device from iommu driver handling
  * @probe_finalize: Do final setup work after the device is added to an IOMMU
@@ -269,6 +287,10 @@ struct iommu_ops {
 
 	/* Domain allocation and freeing by the iommu driver */
 	struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
+	struct iommu_domain *(*domain_alloc_user)(struct device *dev,
+						  struct iommu_domain *parent,
+						  const union iommu_domain_user_data *user_data);
+	int (*domain_alloc_user_data_len)(u32 hwpt_type);
 
 	struct iommu_device *(*probe_device)(struct device *dev);
 	void (*release_device)(struct device *dev);
-- 
2.34.1


  reply	other threads:[~2023-05-11 14:38 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 14:38 [PATCH v2 00/11] iommufd: Add nesting infrastructure Yi Liu
2023-05-11 14:38 ` Yi Liu [this message]
2023-05-19  8:47   ` [PATCH v2 01/11] iommu: Add new iommu op to create domains owned by userspace Tian, Kevin
2023-05-19 18:45     ` Nicolin Chen
2023-05-24  5:02       ` Tian, Kevin
2023-05-24  5:23         ` Nicolin Chen
2023-05-24  7:48           ` Tian, Kevin
2023-05-25  1:41             ` Nicolin Chen
2023-06-06 14:08               ` Jason Gunthorpe
2023-06-06 19:43                 ` Nicolin Chen
2023-06-07  0:14                   ` Jason Gunthorpe
2023-05-11 14:38 ` [PATCH v2 02/11] iommu: Add nested domain support Yi Liu
2023-05-19  8:51   ` Tian, Kevin
2023-05-19 18:49     ` Nicolin Chen
2023-05-24  5:03       ` Tian, Kevin
2023-05-24  5:28         ` Nicolin Chen
2023-05-11 14:38 ` [PATCH v2 03/11] iommufd/hw_pagetable: Use domain_alloc_user op for domain allocation Yi Liu
2023-05-19  8:56   ` Tian, Kevin
2023-05-19 18:57     ` Nicolin Chen
2023-05-24  5:04       ` Tian, Kevin
2023-05-11 14:38 ` [PATCH v2 04/11] iommufd: Pass parent hwpt and user_data to iommufd_hw_pagetable_alloc() Yi Liu
2023-05-19  9:06   ` Tian, Kevin
2023-05-19 19:09     ` Nicolin Chen
2023-05-24  5:11       ` Tian, Kevin
2023-05-24  5:31         ` Nicolin Chen
2023-05-19  9:34   ` Tian, Kevin
2023-05-19 19:12     ` Nicolin Chen
2023-05-11 14:38 ` [PATCH v2 05/11] iommufd/hw_pagetable: Do not populate user-managed hw_pagetables Yi Liu
2023-05-11 14:38 ` [PATCH v2 06/11] iommufd: IOMMU_HWPT_ALLOC allocation with user data Yi Liu
2023-05-17  3:08   ` Liu, Jingqi
2023-05-19 19:34     ` Nicolin Chen
2023-05-19  9:41   ` Tian, Kevin
2023-05-19 19:48     ` Nicolin Chen
2023-05-24  5:16       ` Tian, Kevin
2023-05-24  5:40         ` Nicolin Chen
2023-05-24  7:55           ` Tian, Kevin
2023-05-11 14:38 ` [PATCH v2 07/11] iommufd: Add IOMMU_HWPT_INVALIDATE Yi Liu
2023-05-11 14:38 ` [PATCH v2 08/11] iommufd/selftest: Add domain_alloc_user() support in iommu mock Yi Liu
2023-05-11 14:38 ` [PATCH v2 09/11] iommufd/selftest: Add coverage for IOMMU_HWPT_ALLOC with user data Yi Liu
2023-05-11 14:38 ` [PATCH v2 10/11] iommufd/selftest: Add IOMMU_TEST_OP_MD_CHECK_IOTLB test op Yi Liu
2023-05-11 14:38 ` [PATCH v2 11/11] iommufd/selftest: Add coverage for IOMMU_HWPT_INVALIDATE ioctl Yi Liu
2023-05-19  9:56 ` [PATCH v2 00/11] iommufd: Add nesting infrastructure Tian, Kevin
2023-05-19 11:49   ` Jason Gunthorpe
2023-05-24  3:48     ` Tian, Kevin
2023-06-06 14:18       ` Jason Gunthorpe
2023-06-16  2:43         ` Tian, Kevin
2023-06-19 12:37           ` Jason Gunthorpe
2023-06-20  1:43             ` Tian, Kevin
2023-06-20 12:47               ` Jason Gunthorpe
2023-06-21  6:02                 ` Tian, Kevin
2023-06-21  7:09                   ` Liu, Yi L
2023-06-21 12:04                   ` Jason Gunthorpe
2023-06-26  6:32                     ` Tian, Kevin
2023-06-21 17:13                   ` Nicolin Chen
2023-06-26  6:42                     ` Tian, Kevin
2023-06-26 13:05                       ` Jason Gunthorpe
2023-06-26 17:28                       ` Nicolin Chen
2023-06-27  6:02                         ` Tian, Kevin
2023-06-27 16:01                           ` Jason Gunthorpe
2023-06-28  2:47                             ` Tian, Kevin
2023-06-28 12:36                               ` Jason Gunthorpe
2023-06-29  2:16                                 ` Tian, Kevin
2023-06-21  8:29                 ` Duan, Zhenzhong
2023-06-21 12:07                   ` Jason Gunthorpe

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=20230511143844.22693-2-yi.l.liu@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=yi.y.sun@linux.intel.com \
    --cc=zhenzhong.duan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).