Messages in this thread | | | Date | Tue, 16 May 2023 09:49:13 +0800 | Subject | Re: [PATCH v3 3/4] iommufd: Add IOMMU_DEVICE_GET_HW_INFO | From | Baolu Lu <> |
| |
On 5/15/23 2:14 PM, Liu, Yi L wrote: >> -----Original Message----- >> From: Baolu Lu<baolu.lu@linux.intel.com> >> Sent: Friday, May 12, 2023 1:39 PM >> To: Liu, Yi L<yi.l.liu@intel.com>;joro@8bytes.org;alex.williamson@redhat.com; >> jgg@nvidia.com; Tian, Kevin<kevin.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, Zhenzhong<zhenzhong.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 Chen<nicolinc@nvidia.com> >>> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com> >>> Signed-off-by: Yi Liu<yi.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
| |