From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <kevin.tian@intel.com>, <will@kernel.org>, <joro@8bytes.org>,
<suravee.suthikulpanit@amd.com>, <robin.murphy@arm.com>,
<dwmw2@infradead.org>, <baolu.lu@linux.intel.com>,
<shuah@kernel.org>, <linux-kernel@vger.kernel.org>,
<iommu@lists.linux.dev>, <linux-arm-kernel@lists.infradead.org>,
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v1 05/16] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl
Date: Thu, 15 Aug 2024 12:46:24 -0700 [thread overview]
Message-ID: <Zr5bENKAYJTvwEBJ@Asurada-Nvidia> (raw)
In-Reply-To: <20240815190848.GP2032816@nvidia.com>
On Thu, Aug 15, 2024 at 04:08:48PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 07, 2024 at 01:10:46PM -0700, Nicolin Chen wrote:
>
> > +int iommufd_viommu_set_vdev_id(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_viommu_set_vdev_id *cmd = ucmd->cmd;
> > + struct iommufd_hwpt_nested *hwpt_nested;
> > + struct iommufd_vdev_id *vdev_id, *curr;
> > + struct iommufd_hw_pagetable *hwpt;
> > + struct iommufd_viommu *viommu;
> > + struct iommufd_device *idev;
> > + int rc = 0;
> > +
> > + if (cmd->vdev_id > ULONG_MAX)
> > + return -EINVAL;
> > +
> > + idev = iommufd_get_device(ucmd, cmd->dev_id);
> > + if (IS_ERR(idev))
> > + return PTR_ERR(idev);
> > + hwpt = idev->igroup->hwpt;
> > +
> > + if (hwpt == NULL || hwpt->obj.type != IOMMUFD_OBJ_HWPT_NESTED) {
> > + rc = -EINVAL;
> > + goto out_put_idev;
> > + }
> > + hwpt_nested = container_of(hwpt, struct iommufd_hwpt_nested, common);
>
> This doesn't seem like a necessary check, the attached hwpt can change
> after this is established, so this can't be an invariant we enforce.
>
> If you want to do 1:1 then somehow directly check if the idev is
> already linked to a viommu.
But idev can't link to a viommu without a proxy hwpt_nested? Even
the stage-2 only configuration should have an identity hwpt_nested
right?
> > +static struct device *
> > +iommufd_viommu_find_device(struct iommufd_viommu *viommu, u64 id)
> > +{
> > + struct iommufd_vdev_id *vdev_id;
> > +
> > + xa_lock(&viommu->vdev_ids);
> > + vdev_id = xa_load(&viommu->vdev_ids, (unsigned long)id);
> > + xa_unlock(&viommu->vdev_ids);
>
> This lock doesn't do anything
>
> > + if (!vdev_id || vdev_id->vdev_id != id)
> > + return NULL;
>
> And this is unlocked
>
> > + return vdev_id->dev;
> > +}
>
> This isn't good.. We can't return the struct device pointer here as
> there is no locking for it anymore. We can't even know it is still
> probed to VFIO anymore.
>
> It has to work by having the iommu driver directly access the xarray
> and the entirely under the spinlock the iommu driver can translate the
> vSID to the pSID and the let go and push the invalidation to HW. No
> races.
Maybe the iommufd_viommu_invalidate ioctl handler should hold that
xa_lock around the viommu->ops->cache_invalidate, and then add lock
assert in iommufd_viommu_find_device?
> > +int iommufd_viommu_unset_vdev_id(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_viommu_unset_vdev_id *cmd = ucmd->cmd;
> > + struct iommufd_vdev_id *vdev_id;
> > + struct iommufd_viommu *viommu;
> > + struct iommufd_device *idev;
> > + int rc = 0;
> > +
> > + idev = iommufd_get_device(ucmd, cmd->dev_id);
> > + if (IS_ERR(idev))
> > + return PTR_ERR(idev);
> > +
> > + viommu = iommufd_get_viommu(ucmd, cmd->viommu_id);
> > + if (IS_ERR(viommu)) {
> > + rc = PTR_ERR(viommu);
> > + goto out_put_idev;
> > + }
> > +
> > + if (idev->dev != iommufd_viommu_find_device(viommu, cmd->vdev_id)) {
>
> Swap the order around != to be more kernely
Ack.
> > + rc = -EINVAL;
> > + goto out_put_viommu;
> > + }
> > +
> > + vdev_id = xa_erase(&viommu->vdev_ids, cmd->vdev_id);
>
> And this whole thing needs to be done under the xa_lock too.
>
> xa_lock(&viommu->vdev_ids);
> vdev_id = xa_load(&viommu->vdev_ids, cmd->vdev_id);
> if (!vdev_id || vdev_id->vdev_id != cmd->vdev_id (????) || vdev_id->dev != idev->dev)
> err
> __xa_erase(&viommu->vdev_ids, cmd->vdev_id);
> xa_unlock((&viommu->vdev_ids);
I've changed to xa_cmpxchg() in my local tree. Would it be simpler?
Thanks
Nicolin
next prev parent reply other threads:[~2024-08-15 19:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 20:10 [PATCH v1 00/16] iommufd: Add VIOMMU infrastructure (Part-1) Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 01/16] iommufd/viommu: Add IOMMUFD_OBJ_VIOMMU and IOMMU_VIOMMU_ALLOC ioctl Nicolin Chen
2024-08-14 16:50 ` Nicolin Chen
2024-08-15 18:11 ` Jason Gunthorpe
2024-08-15 18:20 ` Nicolin Chen
2024-08-15 23:37 ` Jason Gunthorpe
2024-08-15 18:31 ` Jason Gunthorpe
2024-08-07 20:10 ` [PATCH v1 02/16] iommu: Pass in a viommu pointer to domain_alloc_user op Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 03/16] iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT_ALLOC Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 04/16] iommufd/selftest: Add IOMMU_VIOMMU_ALLOC test coverage Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 05/16] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl Nicolin Chen
2024-08-14 17:09 ` Nicolin Chen
2024-08-14 22:02 ` Jason Gunthorpe
2024-08-15 19:08 ` Jason Gunthorpe
2024-08-15 19:46 ` Nicolin Chen [this message]
2024-08-15 19:53 ` Nicolin Chen
2024-08-15 23:42 ` Jason Gunthorpe
2024-08-15 23:41 ` Jason Gunthorpe
2024-08-16 0:21 ` Nicolin Chen
2024-08-19 17:33 ` Jason Gunthorpe
2024-08-19 18:10 ` Nicolin Chen
2024-08-19 18:26 ` Jason Gunthorpe
2024-08-07 20:10 ` [PATCH v1 06/16] iommufd/selftest: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID test coverage Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 07/16] iommufd/viommu: Add cache_invalidate for IOMMU_VIOMMU_TYPE_DEFAULT Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 08/16] iommufd/viommu: Add IOMMU_VIOMMU_INVALIDATE ioctl Nicolin Chen
2024-08-15 23:24 ` Jason Gunthorpe
2024-08-15 23:51 ` Nicolin Chen
2024-08-19 17:30 ` Jason Gunthorpe
2024-08-19 17:49 ` Nicolin Chen
2024-08-19 18:20 ` Jason Gunthorpe
2024-08-19 18:22 ` Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 09/16] iommufd/viommu: Make iommufd_viommu_find_device a public API Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 10/16] iommufd/selftest: Add mock_viommu_invalidate_user op Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 11/16] iommufd/selftest: Add IOMMU_TEST_OP_DEV_CHECK_CACHE test command Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 12/16] iommufd/selftest: Add coverage for IOMMU_VIOMMU_INVALIDATE ioctl Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 13/16] iommufd/viommu: Add iommufd_viommu_to_parent_domain helper Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 14/16] iommu/arm-smmu-v3: Extract an __arm_smmu_cache_invalidate_user helper Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 15/16] iommu/arm-smmu-v3: Add viommu cache invalidation support Nicolin Chen
2024-08-15 23:36 ` Jason Gunthorpe
2024-08-16 0:50 ` Nicolin Chen
2024-08-19 17:36 ` Jason Gunthorpe
2024-08-19 18:19 ` Nicolin Chen
2024-08-19 18:28 ` Jason Gunthorpe
2024-08-19 18:38 ` Nicolin Chen
2024-08-19 18:47 ` Jason Gunthorpe
2024-08-19 18:54 ` Nicolin Chen
2024-08-07 20:10 ` [PATCH v1 16/16] iommu/arm-smmu-v3: Allow ATS for IOMMU_DOMAIN_NESTED 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=Zr5bENKAYJTvwEBJ@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=will@kernel.org \
/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.