[v6,0/4] iommufd: Add iommu hardware info reporting

iommufd gives userspace the capability to manipulate iommu subsytem.
e.g. DMA map/unmap etc. In the near future, it will support iommu nested
translation. Different platform vendors have different implementation for
the nested translation. For example, Intel VT-d supports using guest I/O
page table as the stage-1 translation table. This requires guest I/O page
table be compatible with hardware IOMMU. So before set up nested translation,
userspace needs to know the hardware iommu information to understand the
nested translation requirements.

This series reports the iommu hardware information for a given device
which has been bound to iommufd. It is preparation work for userspace to
allocate hwpt for given device. Like the nested translation support[1].

This series introduces an iommu op to report the iommu hardware info,
and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to
user. enum iommu_hw_info_type is defined to differentiate the iommu hardware
info reported to user hence user can decode them. This series only adds the
framework for iommu hw info reporting, the complete reporting path needs vendor
specific definition and driver support. The full code is available in [1]
as well.

[1] https://github.com/yiliu1765/iommufd/tree/wip/iommufd_nesting_08082023-yi
(only the hw_info report path is the latest, other parts is wip)

Change log:

v6:
 - Add Jingqi's comment on patch 02
 - Add Baolu's r-b to patch 03
 - Address Jason's comment on patch 03

v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.com/
 - Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin)
 - Add Jason's r-b for patch 01
 - Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04

v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.com/
 - Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info
 - Move the iommufd_get_hw_info handler to main.c
 - Place iommu_hw_info prior to iommu_hwpt_alloc
 - Update the function namings accordingly
 - Update uapi kdocs

v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.com/#t
 - Add r-b from Baolu
 - Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to
   better suit what it means
 - 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/

v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.com/
 - Drop patch 05 of v1 as it is already covered by other series
 - Rename the capability info to be iommu hardware info

v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.com/

Regards,
	Yi Liu

Lu Baolu (1):
  iommu: Add new iommu op to get iommu hardware information

Nicolin Chen (1):
  iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl

Yi Liu (2):
  iommu: Move dev_iommu_ops() to private header
  iommufd: Add IOMMU_GET_HW_INFO

 drivers/iommu/iommu-priv.h                    | 11 +++
 drivers/iommu/iommufd/iommufd_test.h          |  9 ++
 drivers/iommu/iommufd/main.c                  | 97 +++++++++++++++++++
 drivers/iommu/iommufd/selftest.c              | 16 +++
 include/linux/iommu.h                         | 20 ++--
 include/uapi/linux/iommufd.h                  | 45 +++++++++
 tools/testing/selftests/iommu/iommufd.c       | 17 +++-
 tools/testing/selftests/iommu/iommufd_utils.h | 26 +++++
 8 files changed, 229 insertions(+), 12 deletions(-)

On Wed, Aug 09, 2023 at 06:16:19PM +0800, Baolu Lu wrote:
> On 2023/8/8 23:35, Yi Liu wrote:
> > +static int iommufd_fill_hw_info(struct device *dev, void __user *user_ptr,
> > +				unsigned int *length, u32 *type)
> > +{
> > +	const struct iommu_ops *ops;
> > +	unsigned int data_len;
> > +	void *data;
> > +	int rc = 0;
> > +
> > +	ops = dev_iommu_ops(dev);
> > +	if (!ops->hw_info) {
> > +		*length = 0;
> > +		*type = IOMMU_HW_INFO_TYPE_NONE;
> > +		return 0;
> > +	}
> > +
> > +	data = ops->hw_info(dev, &data_len, type);
> > +	if (IS_ERR(data))
> > +		return PTR_ERR(data);
> > +
> > +	/*
> > +	 * drivers that have hw_info callback should have a unique
> > +	 * iommu_hw_info_type.
> > +	 */
> > +	if (WARN_ON_ONCE(*type == IOMMU_HW_INFO_TYPE_NONE)) {
> > +		rc = -ENODEV;
> > +		goto err_free;
> > +	}
> > +
> > +	*length = min(*length, data_len);
> > +	if (copy_to_user(user_ptr, data, *length)) {
> 
> copy_to_user() returns the number of bytes that were successfully
> copied, right?

It returns length on failure and 0 on success

Jason

On Tue, Aug 08, 2023 at 08:35:09AM -0700, Yi Liu wrote:
> +static int iommufd_zero_fill_user(void __user *ptr, size_t bytes)
> +{
> +	int index = 0;
> +
> +	for (; index < bytes; index++) {
> +		if (put_user(0, (uint8_t __user *)(ptr + index)))
> +			return -EFAULT;
> +	}

I've recently learned this routine is spelled 'clear_user()'

Jason