All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: joro@8bytes.org, kevin.tian@intel.com, baolu.lu@linux.intel.com,
	iommu@lists.linux.dev, robin.murphy@arm.com, nicolinc@nvidia.com,
	will@kernel.org
Subject: Re: [PATCH 5/5] iommu: Retire group->domain
Date: Tue, 18 Feb 2025 15:57:56 -0400	[thread overview]
Message-ID: <20250218195756.GG4183890@nvidia.com> (raw)
In-Reply-To: <20250212060540.261436-6-yi.l.liu@intel.com>

On Tue, Feb 11, 2025 at 10:05:40PM -0800, Yi Liu wrote:
>  static int __iommu_attach_device(struct iommu_domain *domain,
>  				 struct device *dev);
>  static int __iommu_attach_group(struct iommu_domain *domain,
> -				struct iommu_group *group);
> +				struct iommu_group *group,
> +				struct iommu_attach_handle *handle);

I think I would split this particular transformation and it's related
into its own patch, it would shrink this alot. It is principally about
sharing the handle and non-handle paths..

> @@ -563,11 +591,12 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
>  	 * iommu_setup_default_domain()
>  	 */
>  	list_add_tail(&gdev->list, &group->devices);
> -	WARN_ON(group->default_domain && !group->domain);
> +	gdomain = iommu_group_domain(group);
> +	WARN_ON(group->default_domain && !gdomain);
>  	if (group->default_domain)
>  		iommu_create_device_direct_mappings(group->default_domain, dev);
> -	if (group->domain) {
> -		ret = __iommu_device_set_domain(group, dev, group->domain, 0);
> +	if (gdomain) {
> +		ret = __iommu_device_set_domain(group, dev, gdomain, 0);
>  		if (ret)
>  			goto err_remove_gdev;
>  	} else if (!group->default_domain && !group_list) {
> @@ -625,6 +654,8 @@ static void __iommu_group_free_device(struct iommu_group *group,
>  {
>  	struct device *dev = grp_dev->dev;
>  
> +	lockdep_assert_held(&group->mutex);
> +
>  	sysfs_remove_link(group->devices_kobj, grp_dev->name);
>  	sysfs_remove_link(&dev->kobj, "iommu_group");
>  
> @@ -637,7 +668,7 @@ static void __iommu_group_free_device(struct iommu_group *group,
>  	 */
>  	if (list_empty(&group->devices))
>  		WARN_ON(group->owner_cnt ||
> -			group->domain != group->default_domain);
> +			iommu_group_domain(group) != group->default_domain);

You could also probably put the conversion of locked group->domain
into iommu_group_domain() into its own patch (though not using the
xarray to start), that conversion looks like 9 hunks.

> +static void *iommu_make_pasid_entry(struct iommu_domain *domain,
> +				    struct iommu_attach_handle *handle);

Should move the helper to the top of the file in the patch that
introduces it

>  static int __iommu_group_set_domain_internal(struct iommu_group *group,
>  					     struct iommu_domain *new_domain,
> +					     struct iommu_attach_handle *handle,
>  					     unsigned int flags)
>  {
>  	struct group_device *last_gdev;
> +	struct iommu_domain *gdomain;
>  	struct group_device *gdev;
> +	void *pasid_entry;
>  	int result;
>  	int ret;
>  
>  	lockdep_assert_held(&group->mutex);
>  
> -	if (group->domain == new_domain)
> +	gdomain = iommu_group_domain(group);
> +	if (gdomain == new_domain)
>  		return 0;

This is not quite right anymore, we could replace a domain with a
handle or viceversa.

Probably like this:

	if (WARN_ON(!new_domain))
		return -EINVAL;

	pasid_entry = iommu_make_pasid_entry(new_domain, handle);
	curr = xa_cmpxchg(&group->pasid_array, IOMMU_NO_PASID, NULL,
			  XA_ZERO_ENTRY, GFP_KERNEL);
	if (xa_is_err(curr))
		return xa_err(curr);
	if (curr == pasid_entry)
		return 0;
	gdomain = decode_pasid_entry(curr);

> @@ -2290,7 +2343,10 @@ static int __iommu_group_set_domain_internal(struct iommu_group *group,
>  			goto err_revert;
>  		}
>  	}
> -	group->domain = new_domain;
> +
> +	pasid_entry = iommu_make_pasid_entry(new_domain, handle);
> +	WARN_ON(xa_is_err(xa_store(&group->pasid_array,
> +				   IOMMU_NO_PASID, pasid_entry, GFP_KERNEL)));

Ah, this flow uses the same as I suggested a few messages ago already!

> @@ -2302,16 +2358,17 @@ static int __iommu_group_set_domain_internal(struct iommu_group *group,
>  	for_each_group_device(group, gdev) {
>  		/*
>  		 * A NULL domain can happen only for first probe, in which case
> -		 * we leave group->domain as NULL and let release clean
> +		 * we leave domain in pasid_array as NULL and let release clean
>  		 * everything up.
>  		 */
> -		if (group->domain)
> +		if (gdomain)
>  			WARN_ON(__iommu_device_set_domain(
> -				group, gdev->dev, group->domain,
> +				group, gdev->dev, gdomain,
>  				IOMMU_SET_DOMAIN_MUST_SUCCEED));
>  		if (gdev == last_gdev)
>  			break;
>  	}
> +	xa_release(&group->pasid_array, IOMMU_NO_PASID);

This does not seem right, the prior flow left group->domain unchanged
here. IMHO just drop it, the xarray is always populated and almost
never has NULL.

Jason

  parent reply	other threads:[~2025-02-18 19:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-12  6:05 [PATCH 0/5] Misc iommu_attach_handle enhancements in iommu core Yi Liu
2025-02-12  6:05 ` [PATCH 1/5] iommu: Make @handle mandatory in iommu_{attach|replace}_group_handle() Yi Liu
2025-02-18 19:09   ` Jason Gunthorpe
2025-02-19 16:48   ` Nicolin Chen
2025-02-20  3:50     ` Yi Liu
2025-02-20  8:21   ` Tian, Kevin
2025-02-12  6:05 ` [PATCH 2/5] iommu: Drop iommu_group_replace_domain() Yi Liu
2025-02-18 19:10   ` Jason Gunthorpe
2025-02-19 16:53   ` Nicolin Chen
2025-02-20  3:51     ` Yi Liu
2025-02-20  8:22   ` Tian, Kevin
2025-02-12  6:05 ` [PATCH 3/5] iommu: Store either domain or handle in group->pasid_array Yi Liu
2025-02-18 19:14   ` Jason Gunthorpe
2025-02-19 17:15   ` Nicolin Chen
2025-02-20  3:51     ` Yi Liu
2025-02-20  8:28     ` Tian, Kevin
2025-02-20  8:27   ` Tian, Kevin
2025-02-12  6:05 ` [PATCH 4/5] iommu: Swap the order of setting group->pasid_array and calling attach op of iommu drivers Yi Liu
2025-02-18 19:27   ` Jason Gunthorpe
2025-02-19  4:29     ` Yi Liu
2025-02-20  8:31     ` Tian, Kevin
2025-02-12  6:05 ` [PATCH 5/5] iommu: Retire group->domain Yi Liu
2025-02-18 19:39   ` Jason Gunthorpe
2025-02-19  6:52     ` Yi Liu
2025-02-19 12:31       ` Yi Liu
2025-02-19 13:10         ` Jason Gunthorpe
2025-02-20  4:01           ` Yi Liu
2025-02-20  8:33             ` Tian, Kevin
2025-02-20 16:18             ` Jason Gunthorpe
2025-02-18 19:57   ` Jason Gunthorpe [this message]
2025-02-19 12:20     ` Yi Liu
2025-02-12 15:25 ` [PATCH 0/5] Misc iommu_attach_handle enhancements in iommu core Jason Gunthorpe
2025-02-13  3:16   ` Yi Liu
2025-02-13 15:08     ` Jason Gunthorpe

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=20250218195756.GG4183890@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=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --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.