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.
Showing the changes to include/uapi (1 of 2 files). Show all
Unified · Split
| @@ -370,4 +370,13 @@ struct iommu_hwpt_alloc { · 369 unmodified lines | ||
| 370 | 370 | __u32 __reserved; |
| 371 | 371 | }; |
| 372 | 372 | #define IOMMU_HWPT_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_ALLOC) |
| 373 | + | |
| 374 | +/** | |
| 375 | + * enum iommu_hw_info_type - IOMMU Hardware Info Types | |
| 376 | + * @IOMMU_HW_INFO_TYPE_NONE: Used by the drivers that do not report hardware | |
| 377 | + * info | |
| 378 | + */ | |
| 379 | +enum iommu_hw_info_type { | |
| 380 | + IOMMU_HW_INFO_TYPE_NONE, | |
| 381 | +}; | |
| 373 | 382 | #endif |