From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: jgg@nvidia.com, kevin.tian@intel.com, corbet@lwn.net,
will@kernel.org, bagasdotme@gmail.com, robin.murphy@arm.com,
joro@8bytes.org, thierry.reding@gmail.com, vdumpa@nvidia.com,
jonathanh@nvidia.com, shuah@kernel.org, jsnitsel@redhat.com,
nathan@kernel.org, peterz@infradead.org, yi.l.liu@intel.com,
mshavit@google.com, zhangzekun11@huawei.com,
iommu@lists.linux.dev, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-tegra@vger.kernel.org, linux-kselftest@vger.kernel.org,
patches@lists.linux.dev, mochs@nvidia.com,
alok.a.tiwari@oracle.com, vasant.hegde@amd.com,
dwmw2@infradead.org, baolu.lu@linux.intel.com
Subject: Re: [PATCH v7 20/28] iommufd: Allow an input data_type via iommu_hw_info
Date: Tue, 1 Jul 2025 12:58:36 +0000 [thread overview]
Message-ID: <aGPbfM2iZP7ww1fC@google.com> (raw)
In-Reply-To: <ebbcdf1437bd1f96aa76e9132eba3c68472403c3.1750966133.git.nicolinc@nvidia.com>
On Thu, Jun 26, 2025 at 12:34:51PM -0700, Nicolin Chen wrote:
> The iommu_hw_info can output via the out_data_type field the vendor data
> type from a driver, but this only allows driver to report one data type.
>
> Now, with SMMUv3 having a Tegra241 CMDQV implementation, it has two sets
> of types and data structs to report.
>
> One way to support that is to use the same type field bidirectionally.
>
> Reuse the same field by adding an "in_data_type", allowing user space to
> request for a specific type and to get the corresponding data.
>
> For backward compatibility, since the ioctl handler has never checked an
> input value, add an IOMMU_HW_INFO_FLAG_INPUT_TYPE to switch between the
> old output-only field and the new bidirectional field.
>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/uapi/linux/iommufd.h | 20 +++++++++++++++++++-
> drivers/iommu/iommufd/device.c | 9 ++++++---
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 6ad361ff9b06..6ae9d2102154 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -628,6 +628,15 @@ enum iommufd_hw_capabilities {
> IOMMU_HW_CAP_PCI_PASID_PRIV = 1 << 2,
> };
>
> +/**
> + * enum iommufd_hw_info_flags - Flags for iommu_hw_info
> + * @IOMMU_HW_INFO_FLAG_INPUT_TYPE: If set, @in_data_type carries an input type
> + * for user space to request for a specific info
> + */
> +enum iommufd_hw_info_flags {
> + IOMMU_HW_INFO_FLAG_INPUT_TYPE = 1 << 0,
> +};
> +
> /**
> * struct iommu_hw_info - ioctl(IOMMU_GET_HW_INFO)
> * @size: sizeof(struct iommu_hw_info)
> @@ -637,6 +646,12 @@ enum iommufd_hw_capabilities {
> * data that kernel supports
> * @data_uptr: User pointer to a user-space buffer used by the kernel to fill
> * the iommu type specific hardware information data
> + * @in_data_type: This shares the same field with @out_data_type, making it be
> + * a bidirectional field. When IOMMU_HW_INFO_FLAG_INPUT_TYPE is
> + * set, an input type carried via this @in_data_type field will
> + * be valid, requesting for the info data to the given type. If
> + * IOMMU_HW_INFO_FLAG_INPUT_TYPE is unset, any input value will
> + * be seen as IOMMU_HW_INFO_TYPE_DEFAULT
> * @out_data_type: Output the iommu hardware info type as defined in the enum
> * iommu_hw_info_type.
> * @out_capabilities: Output the generic iommu capability info type as defined
> @@ -666,7 +681,10 @@ struct iommu_hw_info {
> __u32 dev_id;
> __u32 data_len;
> __aligned_u64 data_uptr;
> - __u32 out_data_type;
> + union {
> + __u32 in_data_type;
> + __u32 out_data_type;
> + };
> __u8 out_max_pasid_log2;
> __u8 __reserved[3];
> __aligned_u64 out_capabilities;
> diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> index 64a51993e6a1..cbd86aabdd1c 100644
> --- a/drivers/iommu/iommufd/device.c
> +++ b/drivers/iommu/iommufd/device.c
> @@ -1506,6 +1506,7 @@ EXPORT_SYMBOL_NS_GPL(iommufd_access_rw, "IOMMUFD");
>
> int iommufd_get_hw_info(struct iommufd_ucmd *ucmd)
> {
> + const u32 SUPPORTED_FLAGS = IOMMU_HW_INFO_FLAG_INPUT_TYPE;
> struct iommu_hw_info *cmd = ucmd->cmd;
> void __user *user_ptr = u64_to_user_ptr(cmd->data_uptr);
> const struct iommu_ops *ops;
> @@ -1515,12 +1516,14 @@ int iommufd_get_hw_info(struct iommufd_ucmd *ucmd)
> void *data;
> int rc;
>
> - if (cmd->flags || cmd->__reserved[0] || cmd->__reserved[1] ||
> - cmd->__reserved[2])
> + if (cmd->flags & ~SUPPORTED_FLAGS)
> + return -EOPNOTSUPP;
> + if (cmd->__reserved[0] || cmd->__reserved[1] || cmd->__reserved[2])
> return -EOPNOTSUPP;
>
> /* Clear the type field since drivers don't support a random input */
> - cmd->out_data_type = IOMMU_HW_INFO_TYPE_DEFAULT;
> + if (!(cmd->flags & IOMMU_HW_INFO_FLAG_INPUT_TYPE))
> + cmd->in_data_type = IOMMU_HW_INFO_TYPE_DEFAULT;
>
> idev = iommufd_get_device(ucmd, cmd->dev_id);
> if (IS_ERR(idev))
Reviewed-by: Pranjal Shrivastava <praan@google.com>
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-07-01 14:30 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 19:34 [PATCH v7 00/28] iommufd: Add vIOMMU infrastructure (Part-4 HW QUEUE) Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 01/28] iommufd: Report unmapped bytes in the error path of iopt_unmap_iova_range Nicolin Chen
2025-07-02 9:39 ` Tian, Kevin
2025-07-04 12:59 ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 02/28] iommufd/viommu: Explicitly define vdev->virt_id Nicolin Chen
2025-07-01 12:30 ` Pranjal Shrivastava
2025-07-02 9:40 ` Tian, Kevin
2025-07-02 19:59 ` Nicolin Chen
2025-07-04 12:59 ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 03/28] iommu: Use enum iommu_hw_info_type for type in hw_info op Nicolin Chen
2025-07-01 12:48 ` Pranjal Shrivastava
2025-07-01 12:51 ` Pranjal Shrivastava
2025-07-02 9:41 ` Tian, Kevin
2025-07-04 13:00 ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 04/28] iommu: Add iommu_copy_struct_to_user helper Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 05/28] iommu: Pass in a driver-level user data structure to viommu_init op Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 06/28] iommufd/viommu: Allow driver-specific user data for a vIOMMU object Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 07/28] iommufd/selftest: Support user_data in mock_viommu_alloc Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 08/28] iommufd/selftest: Add coverage for viommu data Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 09/28] iommufd/access: Add internal APIs for HW queue to use Nicolin Chen
2025-07-02 9:42 ` Tian, Kevin
2025-07-04 13:08 ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 10/28] iommufd/access: Bypass access->ops->unmap for internal use Nicolin Chen
2025-07-02 9:45 ` Tian, Kevin
2025-07-02 20:12 ` Nicolin Chen
2025-07-03 4:57 ` Tian, Kevin
2025-07-04 4:08 ` Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 11/28] iommufd/viommu: Add driver-defined vDEVICE support Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 12/28] iommufd/viommu: Introduce IOMMUFD_OBJ_HW_QUEUE and its related struct Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 13/28] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl Nicolin Chen
2025-07-04 13:26 ` Jason Gunthorpe
2025-07-04 13:33 ` Jason Gunthorpe
2025-06-26 19:34 ` [PATCH v7 14/28] iommufd/driver: Add iommufd_hw_queue_depend/undepend() helpers Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 15/28] iommufd/selftest: Add coverage for IOMMUFD_CMD_HW_QUEUE_ALLOC Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 16/28] iommufd: Add mmap interface Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 17/28] iommufd/selftest: Add coverage for the new " Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 18/28] Documentation: userspace-api: iommufd: Update HW QUEUE Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 19/28] iommu: Allow an input type in hw_info op Nicolin Chen
2025-07-01 12:54 ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 20/28] iommufd: Allow an input data_type via iommu_hw_info Nicolin Chen
2025-07-01 12:58 ` Pranjal Shrivastava [this message]
2025-06-26 19:34 ` [PATCH v7 21/28] iommufd/selftest: Update hw_info coverage for an input data_type Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 22/28] iommu/arm-smmu-v3-iommufd: Add vsmmu_size/type and vsmmu_init impl ops Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 23/28] iommu/arm-smmu-v3-iommufd: Add hw_info to impl_ops Nicolin Chen
2025-07-01 12:24 ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 24/28] iommu/tegra241-cmdqv: Use request_threaded_irq Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 25/28] iommu/tegra241-cmdqv: Simplify deinit flow in tegra241_cmdqv_remove_vintf() Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 26/28] iommu/tegra241-cmdqv: Do not statically map LVCMDQs Nicolin Chen
2025-06-26 19:34 ` [PATCH v7 27/28] iommu/tegra241-cmdqv: Add user-space use support Nicolin Chen
2025-07-01 16:02 ` Pranjal Shrivastava
2025-07-01 19:42 ` Nicolin Chen
2025-07-01 20:03 ` Pranjal Shrivastava
2025-07-01 20:23 ` Nicolin Chen
2025-07-01 20:43 ` Pranjal Shrivastava
2025-07-01 22:07 ` Nicolin Chen
2025-07-01 22:51 ` Pranjal Shrivastava
2025-07-01 23:01 ` Nicolin Chen
2025-07-02 0:14 ` Pranjal Shrivastava
2025-07-02 0:46 ` Nicolin Chen
2025-07-02 1:38 ` Pranjal Shrivastava
2025-07-02 18:05 ` Jason Gunthorpe
2025-07-03 14:46 ` Pranjal Shrivastava
2025-07-03 17:55 ` Jason Gunthorpe
2025-07-03 18:48 ` Pranjal Shrivastava
2025-07-04 12:50 ` Jason Gunthorpe
2025-07-10 9:04 ` Pranjal Shrivastava
2025-06-26 19:34 ` [PATCH v7 28/28] iommu/tegra241-cmdqv: Add IOMMU_VEVENTQ_TYPE_TEGRA241_CMDQV support Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGPbfM2iZP7ww1fC@google.com \
--to=praan@google.com \
--cc=alok.a.tiwari@oracle.com \
--cc=bagasdotme@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mochs@nvidia.com \
--cc=mshavit@google.com \
--cc=nathan@kernel.org \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vasant.hegde@amd.com \
--cc=vdumpa@nvidia.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=zhangzekun11@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.