From: Nicolin Chen <nicolinc@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: <jgg@nvidia.com>, <kevin.tian@intel.com>, <robin.murphy@arm.com>,
<eric.auger@redhat.com>, <yi.l.liu@intel.com>, <will@kernel.org>,
<joro@8bytes.org>, <shameerali.kolothum.thodi@huawei.com>,
<jean-philippe@linaro.org>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v3 2/4] iommufd: Add IOMMUFD_CMD_DEVICE_SET_DATA and IOMMUFD_CMD_DEVICE_UNSET_DATA
Date: Mon, 24 Apr 2023 11:50:46 -0700 [thread overview]
Message-ID: <ZEbPhorHgaaY0HkP@Asurada-Nvidia> (raw)
In-Reply-To: <17342260-0795-9636-8408-0ca0d6c50403@linux.intel.com>
Hi Baolu,
On Mon, Apr 24, 2023 at 10:44:08AM +0800, Baolu Lu wrote:
> On 4/23/23 3:40 PM, Nicolin Chen wrote:
> > Add a new pair of ioctls to allow user space to set and unset its iommu-
> > specific device data for a passthrough device that's behind the iommu.
> >
> > On platforms with SMMUv3, this new uAPIs will be used to forward a user
> > space virtual Stream ID of a passthrough device to link to its physical
> > Stream ID and log into a lookup table, in order for the host kernel to
> > later run sanity on ATC invalidation requests from the user space, with
> > ATC_INV commands that have SID fields (virtual Stream IDs).
> >
> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> > ---
> > drivers/iommu/iommufd/device.c | 81 +++++++++++++++++++++++++
> > drivers/iommu/iommufd/iommufd_private.h | 3 +
> > drivers/iommu/iommufd/main.c | 4 ++
> > include/uapi/linux/iommufd.h | 32 ++++++++++
> > 4 files changed, 120 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> > index c649a3403797..9480cd36a8bd 100644
> > --- a/drivers/iommu/iommufd/device.c
> > +++ b/drivers/iommu/iommufd/device.c
> > @@ -136,6 +136,8 @@ void iommufd_device_destroy(struct iommufd_object *obj)
> > struct iommufd_device *idev =
> > container_of(obj, struct iommufd_device, obj);
> >
> > + if (WARN_ON(idev->has_user_data))
> > + dev_iommu_ops(idev->dev)->unset_dev_user_data(idev->dev);
>
> Do you really need this WARN_ON()? The user space application can easily
> trigger this kernel WARN() by setting the user data and forgetting to
> unset it.
I can drop that, since it's a user triggerable one.
Thanks
Nic
WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicolinc@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: <jgg@nvidia.com>, <kevin.tian@intel.com>, <robin.murphy@arm.com>,
<eric.auger@redhat.com>, <yi.l.liu@intel.com>, <will@kernel.org>,
<joro@8bytes.org>, <shameerali.kolothum.thodi@huawei.com>,
<jean-philippe@linaro.org>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v3 2/4] iommufd: Add IOMMUFD_CMD_DEVICE_SET_DATA and IOMMUFD_CMD_DEVICE_UNSET_DATA
Date: Mon, 24 Apr 2023 11:50:46 -0700 [thread overview]
Message-ID: <ZEbPhorHgaaY0HkP@Asurada-Nvidia> (raw)
In-Reply-To: <17342260-0795-9636-8408-0ca0d6c50403@linux.intel.com>
Hi Baolu,
On Mon, Apr 24, 2023 at 10:44:08AM +0800, Baolu Lu wrote:
> On 4/23/23 3:40 PM, Nicolin Chen wrote:
> > Add a new pair of ioctls to allow user space to set and unset its iommu-
> > specific device data for a passthrough device that's behind the iommu.
> >
> > On platforms with SMMUv3, this new uAPIs will be used to forward a user
> > space virtual Stream ID of a passthrough device to link to its physical
> > Stream ID and log into a lookup table, in order for the host kernel to
> > later run sanity on ATC invalidation requests from the user space, with
> > ATC_INV commands that have SID fields (virtual Stream IDs).
> >
> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> > ---
> > drivers/iommu/iommufd/device.c | 81 +++++++++++++++++++++++++
> > drivers/iommu/iommufd/iommufd_private.h | 3 +
> > drivers/iommu/iommufd/main.c | 4 ++
> > include/uapi/linux/iommufd.h | 32 ++++++++++
> > 4 files changed, 120 insertions(+)
> >
> > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
> > index c649a3403797..9480cd36a8bd 100644
> > --- a/drivers/iommu/iommufd/device.c
> > +++ b/drivers/iommu/iommufd/device.c
> > @@ -136,6 +136,8 @@ void iommufd_device_destroy(struct iommufd_object *obj)
> > struct iommufd_device *idev =
> > container_of(obj, struct iommufd_device, obj);
> >
> > + if (WARN_ON(idev->has_user_data))
> > + dev_iommu_ops(idev->dev)->unset_dev_user_data(idev->dev);
>
> Do you really need this WARN_ON()? The user space application can easily
> trigger this kernel WARN() by setting the user data and forgetting to
> unset it.
I can drop that, since it's a user triggerable one.
Thanks
Nic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-24 18:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 7:40 [PATCH RFC v3 0/4] Add set_dev_data and unset_dev_data support Nicolin Chen
2023-04-23 7:40 ` Nicolin Chen
2023-04-23 7:40 ` [PATCH RFC v3 1/4] iommu: Add set/unset_dev_user_data ops Nicolin Chen
2023-04-23 7:40 ` Nicolin Chen
2023-04-23 7:40 ` [PATCH RFC v3 2/4] iommufd: Add IOMMUFD_CMD_DEVICE_SET_DATA and IOMMUFD_CMD_DEVICE_UNSET_DATA Nicolin Chen
2023-04-23 7:40 ` Nicolin Chen
2023-04-24 2:44 ` Baolu Lu
2023-04-24 2:44 ` Baolu Lu
2023-04-24 18:50 ` Nicolin Chen [this message]
2023-04-24 18:50 ` Nicolin Chen
2023-04-23 7:40 ` [PATCH RFC v3 3/4] iommufd/selftest: Add IOMMU_TEST_OP_DEV_CHECK_DATA Nicolin Chen
2023-04-23 7:40 ` Nicolin Chen
2023-04-23 7:40 ` [PATCH RFC v3 4/4] iommufd/selftests: Add coverage for IOMMU_DEVICE_SET/UNSET_DATA Nicolin Chen
2023-04-23 7:40 ` 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=ZEbPhorHgaaY0HkP@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--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=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.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.