From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: kevin.tian@intel.com, joro@8bytes.org, baolu.lu@linux.intel.com,
iommu@lists.linux.dev, nicolinc@nvidia.com
Subject: Re: [PATCH v8 06/12] iommufd: Support pasid attach/replace
Date: Fri, 28 Feb 2025 11:32:52 -0400 [thread overview]
Message-ID: <20250228153252.GZ39591@nvidia.com> (raw)
In-Reply-To: <20250226114032.4591-7-yi.l.liu@intel.com>
On Wed, Feb 26, 2025 at 03:40:26AM -0800, Yi Liu wrote:
> This introduces three APIs for device drivers to manage pasid attach/
> replace/detach.
>
> int iommufd_device_pasid_attach(struct iommufd_device *idev,
> ioasid_t pasid, u32 *pt_id);
> int iommufd_device_pasid_replace(struct iommufd_device *idev,
> ioasid_t pasid, u32 *pt_id);
> void iommufd_device_pasid_detach(struct iommufd_device *idev,
> ioasid_t pasid);
>
> The pasid operations share underlying attach/replace/detach infrastructure
> with the device operations, but still have some different implications:
You don't want to just add a PASID to the existing APIs and keep with
PASID=0 means no pasid?
> @@ -136,6 +136,7 @@ void iommufd_device_destroy(struct iommufd_object *obj)
> struct iommufd_device *idev =
> container_of(obj, struct iommufd_device, obj);
>
> + WARN_ON(!xa_empty(&idev->pasid_hwpts));
Should this be in the igroup? That's what the core code does, so some
of the protections you have here won't match the core's version if we
ever see a multi-device pasid capable group.
> + if (pasid != IOMMU_NO_PASID && !hwpt->pasid_compat)
> + return -EINVAL;
This hunks could safely go in the prior patch adding the pasid_compat?
> @@ -417,6 +418,31 @@ iommufd_get_device(struct iommufd_ucmd *ucmd, u32 id)
> void iommufd_device_destroy(struct iommufd_object *obj);
> int iommufd_get_hw_info(struct iommufd_ucmd *ucmd);
>
> +typedef struct iommufd_hw_pagetable *(*attach_fn)(
> + struct iommufd_device *idev, ioasid_t pasid,
> + struct iommufd_hw_pagetable *hwpt);
> +
> +int iommufd_hwpt_attach_device(struct iommufd_hw_pagetable *hwpt,
> + struct iommufd_device *idev,
> + ioasid_t pasid);
> +void iommufd_hwpt_detach_device(struct iommufd_hw_pagetable *hwpt,
> + struct iommufd_device *idev,
> + ioasid_t pasid);
> +int iommufd_hwpt_replace_device(struct iommufd_device *idev,
> + ioasid_t pasid,
> + struct iommufd_hw_pagetable *hwpt,
> + struct iommufd_hw_pagetable *old);
> +
> +int iommufd_device_change_pt(struct iommufd_device *idev, ioasid_t pasid,
> + u32 *pt_id, attach_fn do_attach);
> +
> +struct iommufd_hw_pagetable *
> +iommufd_device_pasid_do_attach(struct iommufd_device *idev, ioasid_t pasid,
> + struct iommufd_hw_pagetable *hwpt);
> +struct iommufd_hw_pagetable *
> +iommufd_device_pasid_do_replace(struct iommufd_device *idev, ioasid_t pasid,
> + struct iommufd_hw_pagetable *hwpt);
Ugh is there going to be alot of stuf fin the pasid.c? Maybe it is
easier to just leave the new functions in device.
> +struct iommufd_hw_pagetable *
> +iommufd_device_pasid_do_attach(struct iommufd_device *idev, ioasid_t pasid,
> + struct iommufd_hw_pagetable *hwpt)
> +{
> + void *curr;
> + int rc;
> +
> + mutex_lock(&idev->igroup->lock);
> + curr = xa_cmpxchg(&idev->pasid_hwpts, pasid, NULL, hwpt, GFP_KERNEL);
> + if (curr) {
I guess you could do the same trick you wanted in the core where the
xarray in the group stores the normal domain too, then I think these
special functions just go away since the xa tests are folded into the
normal functions in place of their normal domain tests?
Jason
next prev parent reply other threads:[~2025-02-28 15:33 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 11:40 [PATCH v8 00/12] iommufd support pasid attach/replace Yi Liu
2025-02-26 11:40 ` [PATCH v8 01/12] iommu: Add iommu_attach_device_pasid_handle() Yi Liu
2025-02-26 13:58 ` Baolu Lu
2025-02-26 22:16 ` Nicolin Chen
2025-02-27 1:27 ` Yi Liu
2025-02-27 16:26 ` Nicolin Chen
2025-02-28 6:48 ` Yi Liu
2025-02-28 15:12 ` Jason Gunthorpe
2025-03-01 10:09 ` Yi Liu
2025-02-28 15:17 ` Jason Gunthorpe
2025-03-01 10:10 ` Yi Liu
2025-03-04 7:34 ` Tian, Kevin
2025-03-04 8:45 ` Yi Liu
2025-02-26 11:40 ` [PATCH v8 02/12] iommu: Introduce a replace API for device pasid Yi Liu
2025-02-26 23:11 ` Nicolin Chen
2025-02-27 1:43 ` Yi Liu
2025-02-27 16:04 ` Nicolin Chen
2025-02-28 14:12 ` Yi Liu
2025-03-01 4:46 ` Nicolin Chen
2025-03-01 10:12 ` Yi Liu
2025-02-27 1:31 ` Baolu Lu
2025-02-27 2:29 ` Yi Liu
2025-02-27 2:59 ` Baolu Lu
2025-02-28 15:21 ` Jason Gunthorpe
2025-03-04 7:42 ` Tian, Kevin
2025-03-04 8:49 ` Yi Liu
2025-03-05 2:36 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 03/12] iommufd: Pass @pasid through the device attach/replace path Yi Liu
2025-02-26 23:45 ` Nicolin Chen
2025-02-28 15:25 ` Jason Gunthorpe
2025-02-26 11:40 ` [PATCH v8 04/12] iommufd/device: Only add reserved_iova in non-pasid path Yi Liu
2025-02-27 0:05 ` Nicolin Chen
2025-02-27 1:50 ` Yi Liu
2025-02-27 16:31 ` Nicolin Chen
2025-02-28 14:03 ` Yi Liu
2025-02-28 15:24 ` Jason Gunthorpe
2025-03-01 10:12 ` Yi Liu
2025-03-04 7:43 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 05/12] iommufd: Mark PASID-compatible domain Yi Liu
2025-02-27 3:06 ` Baolu Lu
2025-02-27 18:58 ` Nicolin Chen
2025-02-28 15:27 ` Jason Gunthorpe
2025-02-26 11:40 ` [PATCH v8 06/12] iommufd: Support pasid attach/replace Yi Liu
2025-02-27 3:27 ` Baolu Lu
2025-02-27 4:19 ` Yi Liu
2025-02-27 20:15 ` Jason Gunthorpe
2025-02-28 14:13 ` Yi Liu
2025-02-28 15:32 ` Jason Gunthorpe [this message]
2025-03-01 11:44 ` Yi Liu
2025-03-03 17:48 ` Jason Gunthorpe
2025-03-04 7:59 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 07/12] iommufd: Enforce PASID-compatible domain for RID Yi Liu
2025-02-27 3:43 ` Baolu Lu
2025-02-27 5:16 ` Yi Liu
2025-02-28 19:39 ` Jason Gunthorpe
2025-03-04 8:00 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 08/12] iommu/vt-d: Add IOMMU_HWPT_ALLOC_PASID support Yi Liu
2025-02-27 3:46 ` Baolu Lu
2025-02-28 19:39 ` Jason Gunthorpe
2025-03-04 8:00 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 09/12] iommufd: Allow allocating PASID-compatible domain Yi Liu
2025-02-27 4:00 ` Baolu Lu
2025-02-27 5:34 ` Yi Liu
2025-02-27 20:17 ` Jason Gunthorpe
2025-02-28 19:56 ` Jason Gunthorpe
2025-03-04 8:08 ` Tian, Kevin
2025-03-04 11:48 ` Yi Liu
2025-03-05 2:38 ` Tian, Kevin
2025-03-13 13:17 ` Yi Liu
2025-03-17 15:35 ` Jason Gunthorpe
2025-02-26 11:40 ` [PATCH v8 10/12] iommufd/selftest: Add set_dev_pasid in mock iommu Yi Liu
2025-03-04 8:08 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 11/12] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2025-03-04 8:09 ` Tian, Kevin
2025-02-26 11:40 ` [PATCH v8 12/12] iommufd/selftest: Add coverage for iommufd " Yi Liu
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=20250228153252.GZ39591@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=nicolinc@nvidia.com \
--cc=yi.l.liu@intel.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.