From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Nicolin Chen <nicolinc@nvidia.com>,
"Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: [PATCH v2 10/17] iommufd: Reorganize iommufd_device_attach into iommufd_device_change_pt
Date: Fri, 10 Mar 2023 11:01:31 -0400 [thread overview]
Message-ID: <ZAtGS5pZF7fnsCJ6@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52760C4E5C89118C1B898DA48CBA9@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Mar 10, 2023 at 11:26:42AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Wednesday, March 8, 2023 8:36 AM
> >
> > @@ -379,52 +388,57 @@ static int
> > iommufd_device_auto_get_domain(struct iommufd_device *idev,
> >
> > if (!iommufd_lock_obj(&hwpt->obj))
> > continue;
> > - rc = iommufd_device_do_attach(idev, hwpt);
> > - iommufd_put_object(&hwpt->obj);
> > -
> > - /*
> > - * -EINVAL means the domain is incompatible with the device.
> > - * Other error codes should propagate to userspace as failure.
> > - * Success means the domain is attached.
> > - */
> > - if (rc == -EINVAL)
> > - continue;
> > + destroy_hwpt = (*do_attach)(idev, hwpt);
> > *pt_id = hwpt->obj.id;
>
> only when succeed?
It isn't necessary, but it can be, it is just more ugly
@@ -461,9 +468,8 @@ iommufd_device_auto_get_domain(struct iommufd_device *idev,
if (!iommufd_lock_obj(&hwpt->obj))
continue;
destroy_hwpt = (*do_attach)(idev, hwpt);
- *pt_id = hwpt->obj.id;
- iommufd_put_object(&hwpt->obj);
if (IS_ERR(destroy_hwpt)) {
+ iommufd_put_object(&hwpt->obj);
/*
* -EINVAL means the domain is incompatible with the
* device. Other error codes should propagate to
@@ -474,6 +480,8 @@ iommufd_device_auto_get_domain(struct iommufd_device *idev,
continue;
goto out_unlock;
}
+ *pt_id = hwpt->obj.id;
+ iommufd_put_object(&hwpt->obj);
goto out_unlock;
}
but sure lets do it
> > + if (IS_ERR(destroy_hwpt)) {
> > + /*
> > + * -EINVAL means the domain is incompatible with
> > the
> > + * device. Other error codes should propagate to
> > + * userspace as failure. Success means the domain is
> > + * attached.
> > + */
> > + if (PTR_ERR(destroy_hwpt) == -EINVAL)
> > + continue;
> > + goto out_unlock;
> > + }
> > goto out_unlock;
>
> two goto's can be merged, if you still want to keep pt_id assignment
> in original place.
Ah, I don't like that so much stylistically.
> > }
> >
> > - hwpt = iommufd_hw_pagetable_alloc(idev->ictx, ioas, idev, true);
> > + hwpt = iommufd_hw_pagetable_alloc(idev->ictx, ioas, idev,
> > + immediate_attach);
> > if (IS_ERR(hwpt)) {
> > - rc = PTR_ERR(hwpt);
> > + destroy_hwpt = ERR_CAST(hwpt);
> > goto out_unlock;
> > }
> > +
> > + if (!immediate_attach) {
> > + destroy_hwpt = (*do_attach)(idev, hwpt);
> > + if (IS_ERR(destroy_hwpt))
> > + goto out_abort;
> > + } else {
> > + destroy_hwpt = NULL;
> > + }
> > +
>
> Above is a bit confusing.
>
> On one hand we have immediate_attach for drivers which must
> complete attach before we can add the domain to iopt. From
> this angle it should always be set when calling
> iommufd_hw_pagetable_alloc() no matter it's attach or replace.
I looked at it for a while if we could make replace follow the same
immediate_attach flow, and it doesn't work right. The problem is we
can fail at iopt_table_add_domain() which would be after replace is
done and at that point we are pretty stuck.
The design of replace is that iommu_group_replace_domain() is the last
failable function in the process.
> On the other hand we assume *replace* doesn't work with
> driver which requires immediate_attach so it's done outside of
> iommufd_hw_pagetable_alloc().
Replace with an IOAS doesn't work on those drivers. It works OK with a
HWPT.
> I'm unsure any better way of handling this transition phase, but
> at least some comment would be useful in this part.
/*
* iommufd_hw_pagetable_attach() is called by
* iommufd_hw_pagetable_alloc() in immediate attachment mode, same as
* iommufd_device_do_attach(). So if we are in this mode then we prefer
* to use the immediate_attach path as it supports drivers that can't
* directly allocate a domain.
*/
bool immediate_attach = do_attach == iommufd_device_do_attach;
Jason
next prev parent reply other threads:[~2023-03-10 15:01 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 0:35 [PATCH v2 00/17] Add iommufd physical device operations for replace and alloc hwpt Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 01/17] iommufd: Move isolated msi enforcement to iommufd_device_bind() Jason Gunthorpe
2023-03-08 2:55 ` Baolu Lu
2023-03-09 12:53 ` Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 02/17] iommufd: Add iommufd_group Jason Gunthorpe
2023-03-08 3:18 ` Baolu Lu
2023-03-09 15:51 ` Jason Gunthorpe
2023-03-10 10:30 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 03/17] iommufd: Replace the hwpt->devices list with iommufd_group Jason Gunthorpe
2023-03-08 11:56 ` Baolu Lu
2023-03-10 10:36 ` Tian, Kevin
2023-03-10 14:16 ` Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 04/17] iommu: Export iommu_get_resv_regions() Jason Gunthorpe
2023-03-08 12:06 ` Baolu Lu
2023-03-08 14:54 ` Jason Gunthorpe
2023-03-10 10:40 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 05/17] iommufd: Keep track of each device's reserved regions instead of groups Jason Gunthorpe
2023-03-08 12:32 ` Baolu Lu
2023-03-08 15:02 ` Jason Gunthorpe
2023-03-09 1:43 ` Baolu Lu
2023-03-10 10:42 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 06/17] iommufd: Use the iommufd_group to avoid duplicate MSI setup Jason Gunthorpe
2023-03-10 10:42 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 07/17] iommufd: Make sw_msi_start a group global Jason Gunthorpe
2023-03-10 10:45 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 08/17] iommufd: Move putting a hwpt to a helper function Jason Gunthorpe
2023-03-08 12:42 ` Baolu Lu
2023-03-10 10:45 ` Tian, Kevin
2023-03-08 0:35 ` [PATCH v2 09/17] iommufd: Add enforced_cache_coherency to iommufd_hw_pagetable_alloc() Jason Gunthorpe
2023-03-08 13:04 ` Baolu Lu
2023-03-08 15:06 ` Jason Gunthorpe
2023-03-09 2:03 ` Baolu Lu
2023-03-09 2:05 ` Baolu Lu
2023-03-08 0:35 ` [PATCH v2 10/17] iommufd: Reorganize iommufd_device_attach into iommufd_device_change_pt Jason Gunthorpe
2023-03-08 13:46 ` Baolu Lu
2023-03-10 11:26 ` Tian, Kevin
2023-03-10 15:01 ` Jason Gunthorpe [this message]
2023-03-08 0:35 ` [PATCH v2 11/17] iommu: Introduce a new iommu_group_replace_domain() API Jason Gunthorpe
2023-03-08 13:48 ` Baolu Lu
2023-03-08 0:35 ` [PATCH v2 12/17] iommufd: Add iommufd_device_replace() Jason Gunthorpe
2023-03-09 1:14 ` Baolu Lu
2023-03-10 11:48 ` Tian, Kevin
2023-03-10 15:04 ` Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 13/17] iommufd: Make destroy_rwsem use a lock class per object type Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 14/17] iommufd/selftest: Test iommufd_device_replace() Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 15/17] iommufd: Add IOMMU_HWPT_ALLOC Jason Gunthorpe
2023-03-09 1:21 ` Baolu Lu
2023-03-08 0:35 ` [PATCH v2 16/17] iommufd/selftest: Return the real idev id from selftest mock_domain Jason Gunthorpe
2023-03-08 0:35 ` [PATCH v2 17/17] iommufd/selftest: Add a selftest for IOMMU_HWPT_ALLOC 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=ZAtGS5pZF7fnsCJ6@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--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.