diff mbox series

[v5,2/4] iommu: Add new iommu op to get iommu hardware information

Message ID 20230803143144.200945-3-yi.l.liu@intel.com (mailing list archive)
State New
Headers show
Series iommufd: Add iommu hardware info reporting | expand

Commit Message

Yi Liu Aug. 3, 2023, 2:31 p.m. UTC
From: Lu Baolu <baolu.lu@linux.intel.com>

Introduce a new iommu op to get the IOMMU hardware capabilities for
iommufd. This information will be used by any vIOMMU driver which is
owned by userspace.

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's room in the design to grow a generic parameter
set as well. No wrapper API is added as it is supposed to be used by
iommufd only.

Different IOMMU hardware would have different hardware information. So the
information reported differs as well. To let the external user understand
the difference. enum iommu_hw_info_type is defined. For the iommu drivers
that are capable to report hardware information, it should have a unique
iommu_hw_info_type and return to caller. For the driver doesn't report
hardware information, caller just uses IOMMU_HW_INFO_TYPE_NONE if a type
is required.

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        | 9 +++++++++
 include/uapi/linux/iommufd.h | 8 ++++++++
 2 files changed, 17 insertions(+)

Comments

Liu, Jingqi Aug. 4, 2023, 2:58 a.m. UTC | #1
On 8/3/2023 10:31 PM, Yi Liu wrote:
> From: Lu Baolu <baolu.lu@linux.intel.com>
>
> Introduce a new iommu op to get the IOMMU hardware capabilities for
> iommufd. This information will be used by any vIOMMU driver which is
> owned by userspace.
>
> 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's room in the design to grow a generic parameter
> set as well. No wrapper API is added as it is supposed to be used by
> iommufd only.
>
> Different IOMMU hardware would have different hardware information. So the
> information reported differs as well. To let the external user understand
> the difference. enum iommu_hw_info_type is defined. For the iommu drivers
> that are capable to report hardware information, it should have a unique
> iommu_hw_info_type and return to caller. For the driver doesn't report
> hardware information, caller just uses IOMMU_HW_INFO_TYPE_NONE if a type
> is required.
>
> 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        | 9 +++++++++
>   include/uapi/linux/iommufd.h | 8 ++++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e0245aa82b75..f2d6a3989713 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -228,6 +228,14 @@ struct iommu_iotlb_gather {
>   /**
>    * struct iommu_ops - iommu ops and capabilities
>    * @capable: check capability
> + * @hw_info: IOMMU hardware information. The type of the returned data is
> + *           marked by the output type of this op. Type is one of
> + *           enum iommu_hw_info_type defined in include/uapi/linux/iommufd.h.
> + *           The drivers that support this op should define a unique type
> + *           in include/uapi/linux/iommufd.h. The data buffer returned by this
> + *           op is allocated in the IOMMU driver and the caller should free it
> + *           after use. Return the data buffer if success, or ERR_PTR on
> + *           failure.
>    * @domain_alloc: allocate iommu domain
>    * @probe_device: Add device to iommu driver handling
>    * @release_device: Remove device from iommu driver handling
> @@ -257,6 +265,7 @@ struct iommu_iotlb_gather {
>    */
>   struct iommu_ops {
>   	bool (*capable)(struct device *dev, enum iommu_cap);
> +	void *(*hw_info)(struct device *dev, u32 *length, u32 *type);
>   
>   	/* Domain allocation and freeing by the iommu driver */
>   	struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 8245c01adca6..1f616b0f8ae0 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -370,4 +370,12 @@ struct iommu_hwpt_alloc {
>   	__u32 __reserved;
>   };
>   #define IOMMU_HWPT_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_ALLOC)
> +
> +/**
> + * enum iommu_hw_info_type - IOMMU Hardware Info Types
> + * @IOMMU_HW_INFO_TYPE_NONE: Used by the drivers that does not report hardware info
It looks like this:
/s/does/do

Thanks,
Jingqi
Yi Liu Aug. 4, 2023, 6:36 a.m. UTC | #2
> From: Liu, Jingqi <jingqi.liu@intel.com>
> Sent: Friday, August 4, 2023 10:58 AM

> > +/**
> > + * enum iommu_hw_info_type - IOMMU Hardware Info Types
> > + * @IOMMU_HW_INFO_TYPE_NONE: Used by the drivers that does not report
> hardware info
> It looks like this:
> /s/does/do

Yes.

Regards,
Yi Liu
diff mbox series

Patch

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e0245aa82b75..f2d6a3989713 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -228,6 +228,14 @@  struct iommu_iotlb_gather {
 /**
  * struct iommu_ops - iommu ops and capabilities
  * @capable: check capability
+ * @hw_info: IOMMU hardware information. The type of the returned data is
+ *           marked by the output type of this op. Type is one of
+ *           enum iommu_hw_info_type defined in include/uapi/linux/iommufd.h.
+ *           The drivers that support this op should define a unique type
+ *           in include/uapi/linux/iommufd.h. The data buffer returned by this
+ *           op is allocated in the IOMMU driver and the caller should free it
+ *           after use. Return the data buffer if success, or ERR_PTR on
+ *           failure.
  * @domain_alloc: allocate iommu domain
  * @probe_device: Add device to iommu driver handling
  * @release_device: Remove device from iommu driver handling
@@ -257,6 +265,7 @@  struct iommu_iotlb_gather {
  */
 struct iommu_ops {
 	bool (*capable)(struct device *dev, enum iommu_cap);
+	void *(*hw_info)(struct device *dev, u32 *length, u32 *type);
 
 	/* Domain allocation and freeing by the iommu driver */
 	struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index 8245c01adca6..1f616b0f8ae0 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -370,4 +370,12 @@  struct iommu_hwpt_alloc {
 	__u32 __reserved;
 };
 #define IOMMU_HWPT_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_ALLOC)
+
+/**
+ * enum iommu_hw_info_type - IOMMU Hardware Info Types
+ * @IOMMU_HW_INFO_TYPE_NONE: Used by the drivers that does not report hardware info
+ */
+enum iommu_hw_info_type {
+	IOMMU_HW_INFO_TYPE_NONE,
+};
 #endif