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 v6 07/25] iommufd/access: Add internal APIs for HW queue to use
Date: Thu, 19 Jun 2025 09:42:59 +0000 [thread overview]
Message-ID: <aFPbo6RI-D4T7nXE@google.com> (raw)
In-Reply-To: <64145b184a0fa7c9b60532c9b475a51625edb77c.1749884998.git.nicolinc@nvidia.com>
On Sat, Jun 14, 2025 at 12:14:32AM -0700, Nicolin Chen wrote:
> Now, access->ops can be NULL, to support an internal use case for the new
> HW queue object. Since an access object in this case will be allocated by
> an inernal iommufd object, the refcount on the ictx should be skipped, so
> as not to deadlock the release of the ictx as it would otherwise wait for
> the release of the access first during the release of the internal object
> that could wait for the release of ictx:
> ictx --releases--> hw_queue --releases--> access
> ^ |
> |_________________releases________________v
>
> Add a set of lightweight internal APIs to unlink access and ictx:
> ictx --releases--> hw_queue --releases--> access
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/iommufd/iommufd_private.h | 8 ++++
> drivers/iommu/iommufd/device.c | 59 +++++++++++++++++++++----
> 2 files changed, 58 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
> index 4a375a8c9216..468717d5e5bc 100644
> --- a/drivers/iommu/iommufd/iommufd_private.h
> +++ b/drivers/iommu/iommufd/iommufd_private.h
> @@ -484,6 +484,14 @@ void iopt_remove_access(struct io_pagetable *iopt,
> struct iommufd_access *access, u32 iopt_access_list_id);
> void iommufd_access_destroy_object(struct iommufd_object *obj);
>
> +/* iommufd_access for internal use */
> +struct iommufd_access *iommufd_access_create_internal(struct iommufd_ctx *ictx);
> +#define iommufd_access_destroy_internal(ictx, access) \
> + iommufd_object_destroy_user(ictx, &(access)->obj)
> +int iommufd_access_attach_internal(struct iommufd_access *access,
> + struct iommufd_ioas *ioas);
> +#define iommufd_access_detach_internal(access) iommufd_access_detach(access)
> +
> struct iommufd_eventq {
> struct iommufd_object obj;
> struct iommufd_ctx *ictx;
> diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> index 9293722b9cff..ad33f1e41a24 100644
> --- a/drivers/iommu/iommufd/device.c
> +++ b/drivers/iommu/iommufd/device.c
> @@ -1084,7 +1084,39 @@ void iommufd_access_destroy_object(struct iommufd_object *obj)
> if (access->ioas)
> WARN_ON(iommufd_access_change_ioas(access, NULL));
> mutex_unlock(&access->ioas_lock);
> - iommufd_ctx_put(access->ictx);
> + if (access->ops)
> + iommufd_ctx_put(access->ictx);
Purely relying on access->ops being NULL feels a bit hacky to me..
> +}
> +
> +static struct iommufd_access *__iommufd_access_create(struct iommufd_ctx *ictx)
> +{
> + struct iommufd_access *access;
> +
> + /*
> + * There is no uAPI for the access object, but to keep things symmetric
> + * use the object infrastructure anyhow.
> + */
> + access = iommufd_object_alloc(ictx, access, IOMMUFD_OBJ_ACCESS);
> + if (IS_ERR(access))
> + return access;
> +
> + /* The calling driver is a user until iommufd_access_destroy() */
> + refcount_inc(&access->obj.users);
> + mutex_init(&access->ioas_lock);
> + return access;
> +}
> +
> +struct iommufd_access *iommufd_access_create_internal(struct iommufd_ctx *ictx)
> +{
> + struct iommufd_access *access;
> +
> + access = __iommufd_access_create(ictx);
> + if (IS_ERR(access))
> + return access;
> + access->iova_alignment = PAGE_SIZE;
Maybe setting acces->ictx = NULL; explicitly here would be a clear
demarcation between the new API for "internal" v/s the original one.
Else, I definitely believe we should have a comment mentioning that
access->ictx is NULL for internal.
> +
> + iommufd_object_finalize(ictx, &access->obj);
> + return access;
> }
>
> /**
> @@ -1106,11 +1138,7 @@ iommufd_access_create(struct iommufd_ctx *ictx,
> {
> struct iommufd_access *access;
>
> - /*
> - * There is no uAPI for the access object, but to keep things symmetric
> - * use the object infrastructure anyhow.
> - */
> - access = iommufd_object_alloc(ictx, access, IOMMUFD_OBJ_ACCESS);
> + access = __iommufd_access_create(ictx);
> if (IS_ERR(access))
> return access;
>
> @@ -1122,13 +1150,10 @@ iommufd_access_create(struct iommufd_ctx *ictx,
> else
> access->iova_alignment = 1;
>
> - /* The calling driver is a user until iommufd_access_destroy() */
> - refcount_inc(&access->obj.users);
> access->ictx = ictx;
> iommufd_ctx_get(ictx);
> iommufd_object_finalize(ictx, &access->obj);
> *id = access->obj.id;
> - mutex_init(&access->ioas_lock);
> return access;
> }
> EXPORT_SYMBOL_NS_GPL(iommufd_access_create, "IOMMUFD");
> @@ -1173,6 +1198,22 @@ int iommufd_access_attach(struct iommufd_access *access, u32 ioas_id)
> }
> EXPORT_SYMBOL_NS_GPL(iommufd_access_attach, "IOMMUFD");
>
> +int iommufd_access_attach_internal(struct iommufd_access *access,
> + struct iommufd_ioas *ioas)
> +{
> + int rc;
> +
> + mutex_lock(&access->ioas_lock);
> + if (WARN_ON(access->ioas)) {
> + mutex_unlock(&access->ioas_lock);
> + return -EINVAL;
> + }
> +
> + rc = iommufd_access_change_ioas(access, ioas);
> + mutex_unlock(&access->ioas_lock);
> + return rc;
> +}
> +
> int iommufd_access_replace(struct iommufd_access *access, u32 ioas_id)
> {
> int rc;
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-06-19 15:44 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-14 7:14 [PATCH v6 00/25] iommufd: Add vIOMMU infrastructure (Part-4 HW QUEUE) Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 01/25] iommu: Add iommu_copy_struct_to_user helper Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 02/25] iommu: Pass in a driver-level user data structure to viommu_init op Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 03/25] iommufd/viommu: Allow driver-specific user data for a vIOMMU object Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 04/25] iommufd/selftest: Support user_data in mock_viommu_alloc Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 05/25] iommufd/selftest: Add coverage for viommu data Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 06/25] iommufd/access: Allow access->ops to be NULL for internal use Nicolin Chen
2025-06-16 6:25 ` Baolu Lu
2025-06-16 13:33 ` Jason Gunthorpe
2025-06-17 2:21 ` Nicolin Chen
2025-06-19 9:14 ` Pranjal Shrivastava
2025-06-25 3:38 ` Tian, Kevin
2025-06-25 16:37 ` Nicolin Chen
2025-06-25 17:33 ` Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 07/25] iommufd/access: Add internal APIs for HW queue to use Nicolin Chen
2025-06-16 13:37 ` Jason Gunthorpe
2025-06-17 2:25 ` Nicolin Chen
2025-06-17 4:23 ` Baolu Lu
2025-06-17 11:55 ` Jason Gunthorpe
2025-06-19 9:49 ` Pranjal Shrivastava
2025-06-19 9:42 ` Pranjal Shrivastava [this message]
2025-06-14 7:14 ` [PATCH v6 08/25] iommufd/viommu: Add driver-defined vDEVICE support Nicolin Chen
2025-06-16 6:26 ` Baolu Lu
2025-06-19 10:26 ` Pranjal Shrivastava
2025-06-19 11:44 ` Jason Gunthorpe
2025-06-21 4:51 ` Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 09/25] iommufd/viommu: Introduce IOMMUFD_OBJ_HW_QUEUE and its related struct Nicolin Chen
2025-06-16 13:47 ` Jason Gunthorpe
2025-06-17 2:29 ` Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 10/25] iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl Nicolin Chen
2025-06-16 6:12 ` Baolu Lu
2025-06-16 6:47 ` Nicolin Chen
2025-06-16 6:54 ` Baolu Lu
2025-06-16 7:04 ` Nicolin Chen
2025-06-16 7:09 ` Baolu Lu
2025-06-25 3:43 ` Tian, Kevin
2025-06-25 16:06 ` Nicolin Chen
2025-06-16 7:11 ` Baolu Lu
2025-06-16 13:58 ` Jason Gunthorpe
2025-06-25 3:45 ` Tian, Kevin
2025-06-25 23:06 ` Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 11/25] iommufd/driver: Add iommufd_hw_queue_depend/undepend() helpers Nicolin Chen
2025-06-16 14:06 ` Jason Gunthorpe
2025-06-14 7:14 ` [PATCH v6 12/25] iommufd/selftest: Add coverage for IOMMUFD_CMD_HW_QUEUE_ALLOC Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 13/25] iommufd: Add mmap interface Nicolin Chen
2025-06-16 11:33 ` Baolu Lu
2025-06-16 14:13 ` Jason Gunthorpe
2025-06-17 2:37 ` Nicolin Chen
2025-06-17 11:55 ` Jason Gunthorpe
2025-06-25 21:18 ` Nicolin Chen
2025-06-19 11:15 ` Pranjal Shrivastava
2025-06-14 7:14 ` [PATCH v6 14/25] iommufd/selftest: Add coverage for the new " Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 15/25] Documentation: userspace-api: iommufd: Update HW QUEUE Nicolin Chen
2025-06-16 11:34 ` Baolu Lu
2025-06-14 7:14 ` [PATCH v6 16/25] iommu: Allow an input type in hw_info op Nicolin Chen
2025-06-16 11:53 ` Baolu Lu
2025-06-14 7:14 ` [PATCH v6 17/25] iommufd: Allow an input data_type via iommu_hw_info Nicolin Chen
2025-06-16 11:54 ` Baolu Lu
2025-06-16 14:14 ` Jason Gunthorpe
2025-06-14 7:14 ` [PATCH v6 18/25] iommufd/selftest: Update hw_info coverage for an input data_type Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 19/25] iommu/arm-smmu-v3-iommufd: Add vsmmu_size/type and vsmmu_init impl ops Nicolin Chen
2025-06-16 14:19 ` Jason Gunthorpe
2025-06-14 7:14 ` [PATCH v6 20/25] iommu/arm-smmu-v3-iommufd: Add hw_info to impl_ops Nicolin Chen
2025-06-16 14:20 ` Jason Gunthorpe
2025-06-19 11:47 ` Pranjal Shrivastava
2025-06-19 18:53 ` Jason Gunthorpe
2025-06-20 3:32 ` Pranjal Shrivastava
2025-06-21 5:36 ` Nicolin Chen
2025-06-23 15:13 ` Pranjal Shrivastava
2025-06-14 7:14 ` [PATCH v6 21/25] iommu/tegra241-cmdqv: Use request_threaded_irq Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 22/25] iommu/tegra241-cmdqv: Simplify deinit flow in tegra241_cmdqv_remove_vintf() Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 23/25] iommu/tegra241-cmdqv: Do not statically map LVCMDQs Nicolin Chen
2025-06-16 15:44 ` Jason Gunthorpe
2025-06-14 7:14 ` [PATCH v6 24/25] iommu/tegra241-cmdqv: Add user-space use support Nicolin Chen
2025-06-16 16:03 ` Jason Gunthorpe
2025-06-26 18:51 ` Nicolin Chen
2025-06-14 7:14 ` [PATCH v6 25/25] 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=aFPbo6RI-D4T7nXE@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.