On 5/15/23 2:14 PM, Liu, Yi L wrote:
-----Original Message----- From: Baolu Lubaolu.lu@linux.intel.com Sent: Friday, May 12, 2023 1:39 PM To: Liu, Yi Lyi.l.liu@intel.com;joro@8bytes.org;alex.williamson@redhat.com; jgg@nvidia.com; Tian, Kevinkevin.tian@intel.com;robin.murphy@arm.com Cc:baolu.lu@linux.intel.com;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.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; Duan, Zhenzhongzhenzhong.duan@intel.com Subject: Re: [PATCH v3 3/4] iommufd: Add IOMMU_DEVICE_GET_HW_INFO
On 5/11/23 10:30 PM, Yi Liu wrote:
Under nested IOMMU translation, userspace owns the stage-1 translation table (e.g. the stage-1 page table of Intel VT-d or the context table of ARM SMMUv3, and etc.). Stage-1 translation tables are vendor specific, and needs to be compatiable with the underlying IOMMU hardware. Hence, userspace should know the IOMMU hardware capability before creating and configuring the stage-1 translation table to kernel.
This adds IOMMU_DEVICE_GET_HW_INFO to query the IOMMU hardware
information
for a given device. The returned data is vendor specific, userspace needs to decode it with the structure mapped by the @out_data_type field.
As only physical devices have IOMMU hardware, so this will return error if the given device is not a physical device.
Co-developed-by: Nicolin Chennicolinc@nvidia.com Signed-off-by: Nicolin Chennicolinc@nvidia.com Signed-off-by: Yi Liuyi.l.liu@intel.com
drivers/iommu/iommufd/device.c | 72 +++++++++++++++++++++++++ drivers/iommu/iommufd/iommufd_private.h | 1 + drivers/iommu/iommufd/main.c | 3 ++ include/uapi/linux/iommufd.h | 37 +++++++++++++ 4 files changed, 113 insertions(+)
diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c index 051bd8e99858..bc99d092de8f 100644 --- a/drivers/iommu/iommufd/device.c +++ b/drivers/iommu/iommufd/device.c @@ -263,6 +263,78 @@ u32 iommufd_device_to_id(struct iommufd_device *idev) } EXPORT_SYMBOL_NS_GPL(iommufd_device_to_id, IOMMUFD);
+static int iommufd_zero_fill_user(u64 ptr, int bytes) +{
- int index = 0;
- for (; index < bytes; index++) {
if (put_user(0, (uint8_t __user *)u64_to_user_ptr(ptr + index)))return -EFAULT;- }
- return 0;
+}
+int iommufd_device_get_hw_info(struct iommufd_ucmd *ucmd) +{
- struct iommu_hw_info *cmd = ucmd->cmd;
- unsigned int length = 0, data_len;
- struct iommufd_device *idev;
- const struct iommu_ops *ops;
- void *data = NULL;
- int rc = 0;
- if (cmd->flags || cmd->__reserved || !cmd->data_len)
return -EOPNOTSUPP;- idev = iommufd_get_device(ucmd, cmd->dev_id);
- if (IS_ERR(idev))
return PTR_ERR(idev);- ops = dev_iommu_ops(idev->dev);
- if (!ops->hw_info)
goto done;If the iommu driver doesn't provide a hw_info callback, it still returns success?
Yes, as noted in the cover letter. It's for a remark from Jason. In such case, the out_data_type is NULL, it means no specific data is filled in the buffer pointed by cmd->data_ptr.
- Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver does not have driver-specific data to report per below remark. https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/
Oh, I overlooked that. Thanks for the explanation. It's fair enough.
Best regards, baolu