ring the allocation) back to user space.
>
> Similar to the existing ioctls and their IOMMU handlers, add a user_data
> to viommu_alloc op to bridge between iommufd and drivers.
>
Ack, with this change (addressing Lu's nit).
Reviewed-by: Pranjal Shrivastava
> Thanks
> Nicolin
e
> Signed-off-by: Nicolin Chen
Acked-by: Pranjal Shrivastava
> ---
> include/uapi/linux/iommufd.h | 6 ++
> drivers/iommu/iommufd/viommu.c | 8 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/
> \
> + __iommu_copy_struct_to_user(user_data, ksrc, data_type, sizeof(*ksrc), \
> + offsetofend(typeof(*ksrc), min_last))
> +
> /**
> * struct iommu_ops - iommu ops and capabilities
> * @capable: check capability
With the above nit.
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
On Fri, Apr 25, 2025 at 10:58:05PM -0700, Nicolin Chen wrote:
> Introduce a new IOMMUFD_CMD_VCMDQ_ALLOC ioctl for user space to allocate
> a vCMDQ for a vIOMMU object. Simply increase the refcount of the vIOMMU.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/iommufd_private.h | 2
e @impl will be only valid if @flags is set with an
> implementation-defined flag.
>
> Thus in the driver-level, add an hw_info impl op that will return such
> a flag to use the impl field.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
> ---
> driv
On Tue, Apr 29, 2025 at 02:46:25PM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 09:35:07PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Apr 29, 2025 at 02:05:12PM -0700, Nicolin Chen wrote:
> > > On Tue, Apr 29, 2025 at 08:55:47PM +, Pranjal Shrivastava wrote:
>
p_lvcmdq(vintf->lvcmdqs[lidx]);
> ret = tegra241_vcmdq_hw_init(vintf->lvcmdqs[lidx]);
> if (ret) {
> tegra241_vintf_hw_deinit(vintf);
> @@ -476,7 +506,6 @@ static int tegra241_cmdqv_hw_reset(struct arm_smmu_device
On Fri, Apr 25, 2025 at 10:58:13PM -0700, Nicolin Chen wrote:
> A vIRQ can be reported only from a threaded IRQ context. Change to use
> to request_threaded_irq to support that.
>
> Signed-off-by: Nicolin Chen
Acked-by: Pranjal Shrivastava
> ---
> drivers/iommu/arm/ar
dev_dbg(cmdqv->dev, "VINTF%u: deallocated\n", vintf->idx);
> tegra241_cmdqv_deinit_vintf(cmdqv, idx);
I don't have access to a HW spec to verify HW behaviour, but the changes
make sense to me.
Acked-by: Pranjal Shrivastava
> --
> 2.43.0
>
On Fri, Apr 25, 2025 at 10:58:17PM -0700, Nicolin Chen wrote:
> Add a new vEVENTQ type for VINTFs that are assigned to the user space.
> Simply report the two 64-bit LVCMDQ_ERR_MAPs register values.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
T
On Fri, Apr 25, 2025 at 10:58:16PM -0700, Nicolin Chen wrote:
> The CMDQV HW supports a user-space use for virtualization cases. It allows
> the VM to issue guest-level TLBI or ATC_INV commands directly to the queue
> and executes them without a VMEXIT, as HW will replace the VMID field in a
> TLBI
On Wed, Apr 30, 2025 at 03:39:15PM -0700, Nicolin Chen wrote:
> On Wed, Apr 30, 2025 at 09:59:13PM +0000, Pranjal Shrivastava wrote:
> > On Fri, Apr 25, 2025 at 10:58:16PM -0700, Nicolin Chen wrote:
> > > The CMDQV HW supports a user-space use for virtualization cases. It allo
On Wed, Apr 30, 2025 at 05:54:41PM -0700, Nicolin Chen wrote:
> On Wed, Apr 30, 2025 at 03:39:22PM -0700, Nicolin Chen wrote:
> > On Wed, Apr 30, 2025 at 09:59:13PM +, Pranjal Shrivastava wrote:
> > > > enum iommu_viommu_type {
> > > >
On Mon, May 05, 2025 at 01:55:52PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 29, 2025 at 02:46:25PM -0700, Nicolin Chen wrote:
> > > > > > > > > + immap = kzalloc(sizeof(*immap), GFP_KERNEL);
> > > > > > > > > + if (!immap)
> > > > > > > > > + return -ENOMEM;
> > > > > > > > >
On Fri, Apr 25, 2025 at 10:58:06PM -0700, Nicolin Chen wrote:
> NVIDIA Virtual Command Queue is one of the iommufd users exposing vIOMMU
> features to user space VMs. Its hardware has a strict rule when mapping
> and unmapping multiple global CMDQVs to/from a VM-owned VINTF, requiring
> mappings in
On Mon, Apr 28, 2025 at 03:44:08PM -0700, Nicolin Chen wrote:
> On Mon, Apr 28, 2025 at 09:34:05PM +0000, Pranjal Shrivastava wrote:
> > On Fri, Apr 25, 2025 at 10:58:05PM -0700, Nicolin Chen wrote:
> > > @@ -501,6 +504,9 @@ static const struct iommufd_object_ops
> &
On Mon, Apr 28, 2025 at 11:21:43AM -0700, Nicolin Chen wrote:
> On Mon, Apr 28, 2025 at 05:50:28PM +0000, Pranjal Shrivastava wrote:
> > On Fri, Apr 25, 2025 at 10:57:59PM -0700, Nicolin Chen wrote:
> > > Similar to the iommu_copy_struct_from_user helper receiving data from th
On Fri, Apr 25, 2025 at 10:58:02PM -0700, Nicolin Chen wrote:
> Extend the existing test_cmd/err_viommu_alloc helpers to accept optional
> user data. And add a TEST_F for a loopback test.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
> ---
> tools/testi
; + rc = iommu_copy_struct_to_user(
> + user_data, &data, IOMMU_VIOMMU_TYPE_SELFTEST, out_data);
> + if (rc) {
> + iommufd_struct_destroy(ictx, mock_viommu, core);
> + return ERR_PTR(rc);
> + }
> + }
> +
> refcount_inc(&mock_iommu->users);
> return &mock_viommu->core;
> }
Builds fine for me.
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
On Fri, Apr 25, 2025 at 10:58:03PM -0700, Nicolin Chen wrote:
> The new vCMDQ object will be added for HW to access the guest memory for a
> HW-accelerated virtualization feature. It needs to ensure the guest memory
> pages are pinned when HW accesses them and they are contiguous in physical
> addr
x27;s, such as:
> - NVIDIA's virtual command queue
> - AMD vIOMMU's command buffer
>
> Inroduce a struct iommufd_vcmdq and its allocator iommufd_vcmdq_alloc().
> Also add a pair of viommu ops for iommufd to forward user space ioctls to
> IOMMU drivers.
>
> Signed-off-by:
On Tue, Apr 29, 2025 at 11:07:42AM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 05:59:32PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Apr 29, 2025 at 10:10:28AM -0700, Nicolin Chen wrote:
> > > On Tue, Apr 29, 2025 at 12:40:07PM +, Pranjal Shrivastava wrote:
>
On Tue, Apr 29, 2025 at 11:15:00AM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 06:10:31PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Apr 29, 2025 at 08:28:01AM +, Pranjal Shrivastava wrote:
> > > On Mon, Apr 28, 2025 at 03:44:08PM -0700, Nicolin Chen wrote:
>
On Tue, Apr 29, 2025 at 10:10:28AM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 12:40:07PM +0000, Pranjal Shrivastava wrote:
> > On Fri, Apr 25, 2025 at 10:58:06PM -0700, Nicolin Chen wrote:
> > > /* Caller should xa_lock(&viommu->vdevs) to protect the return valu
On Tue, Apr 29, 2025 at 08:28:01AM +, Pranjal Shrivastava wrote:
> On Mon, Apr 28, 2025 at 03:44:08PM -0700, Nicolin Chen wrote:
> > On Mon, Apr 28, 2025 at 09:34:05PM +, Pranjal Shrivastava wrote:
> > > On Fri, Apr 25, 2025 at 10:58:05PM -0700, Nicolin Chen wrote:
> [
On Mon, Apr 28, 2025 at 04:34:14PM -0700, Nicolin Chen wrote:
> On Mon, Apr 28, 2025 at 03:12:33PM -0700, Nicolin Chen wrote:
> > On Mon, Apr 28, 2025 at 08:14:19PM +, Pranjal Shrivastava wrote:
> > > On Fri, Apr 25, 2025 at 10:58:03PM -0700,
On Fri, Apr 25, 2025 at 10:58:08PM -0700, Nicolin Chen wrote:
> For vIOMMU passing through HW resources to user space (VMs), add an mmap
> infrastructure to map a region of hardware MMIO pages.
>
> Maintain an mt_mmap per ictx for validations. To allow IOMMU drivers to
> add and delete mmappable r
On Tue, Apr 29, 2025 at 08:24:33PM +, Pranjal Shrivastava wrote:
> On Fri, Apr 25, 2025 at 10:58:08PM -0700, Nicolin Chen wrote:
> > For vIOMMU passing through HW resources to user space (VMs), add an mmap
> > infrastructure to map a region of hardware MMIO pages.
> >
&g
On Tue, Apr 29, 2025 at 01:39:09PM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 08:34:56PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Apr 29, 2025 at 08:24:33PM +, Pranjal Shrivastava wrote:
> > > On Fri, Apr 25, 2025 at 10:58:08PM -0700, Nicolin Chen wrote:
>
On Tue, Apr 29, 2025 at 02:05:12PM -0700, Nicolin Chen wrote:
> On Tue, Apr 29, 2025 at 08:55:47PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Apr 29, 2025 at 01:39:09PM -0700, Nicolin Chen wrote:
> > > On Tue, Apr 29, 2025 at 08:34:56PM +, Pranjal Shrivastava wrote:
>
allocation for IOMMU_VIOMMU_TYPE_ARM_SMMUV3.
>
> Signed-off-by: Nicolin Chen
Reviewd-by: Pranjal Shrivastava
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 17 +++--
> 2 files changed, 17 insertions(+),
On Tue, Feb 18, 2025 at 05:24:08AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Saturday, January 25, 2025 8:31 AM
> >
> > There is a DoS concern on the shared hardware event queue among devices
> > passed through to VMs, that too many translation failures that belong to
> > VMs cou
On Thu, Feb 27, 2025 at 04:12:04AM +, Mina Almasry wrote:
> int mp_dmabuf_devmem_init(struct page_pool *pool)
> diff --git a/net/core/devmem.h b/net/core/devmem.h
> index 946f2e015746..67168aae5e5b 100644
> --- a/net/core/devmem.h
> +++ b/net/core/devmem.h
> @@ -23,8 +23,9 @@ struct net_devmem
On Mon, Feb 24, 2025 at 01:31:11PM -0800, Nicolin Chen wrote:
> On Mon, Feb 24, 2025 at 08:35:56PM +0000, Pranjal Shrivastava wrote:
> > oN sAt, Feb 22, 2025 at 07:54:09AM -0800, Nicolin Chen wrote:
> > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> &g
On Sat, Feb 22, 2025 at 07:54:10AM -0800, Nicolin Chen wrote:
> Aside from the IOPF framework, iommufd provides an additional pathway to
> report hardware events, via the vEVENTQ of vIOMMU infrastructure.
>
> Define an iommu_vevent_arm_smmuv3 uAPI structure, and report stage-1 events
> in the thre
oN sAt, Feb 22, 2025 at 07:54:09AM -0800, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> index 5aa2e7af58b4..364d8469a480 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> +++ b/dri
mmufd.c | 2 ++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
Reviewed-by: Pranjal Shrivastava
Thanks,
Praan
On Tue, Feb 18, 2025 at 10:53:55AM -0800, Nicolin Chen wrote:
> > > Is MEV available only in nested mode? Otherwise it perhaps makes
> > > sense to turn it on in all configurations in IOMMUFD paths...
> >
> > I think the arm-smmu-v3's iommufd implementation only supports nested
> > which could be
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 2 ++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
Apologies for my spelling error in [1]. It's supposed to be:
Reviewed-by: Pranjal Shrivastava
Correct sp
On Mon, Feb 24, 2025 at 07:35:05PM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 24, 2025 at 01:56:46PM -0800, Nicolin Chen wrote:
>
> > > Just thinking out loud here:
> > > I understand the goal here is to "emulate" an IOMMU. But I'm just
> > > wondering if we could report struct events instead of
ologies for my spelling error in [1]. It's supposed to be:
Reviewed-by: Pranjal Shrivastava
Correct spelling in [2].
Thanks,
Praan
[1] https://lore.kernel.org/all/z73zvibsxzjmc...@google.com/
[2] https://lore.kernel.org/all/z730m3xptvdro...@google.com/
m-smmu-v3-iommufd.c | 45 +++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 +++-
> 3 files changed, 90 insertions(+), 1 deletion(-)
>
Apologies for my spelling error in [1]. It's supposed to be:
Reviewed-by: Pranjal Shrivastava
For all the other patches
On Tue, Feb 25, 2025 at 08:41:27AM -0800, Nicolin Chen wrote:
> On Tue, Feb 25, 2025 at 12:02:25PM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 24, 2025 at 03:45:33PM -0800, Nicolin Chen wrote:
> >
> > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> > > +++ b/drivers/iommu/arm/arm-s
On Mon, Feb 24, 2025 at 01:56:46PM -0800, Nicolin Chen wrote:
> On Mon, Feb 24, 2025 at 09:35:14PM +0000, Pranjal Shrivastava wrote:
> > On Sat, Feb 22, 2025 at 07:54:10AM -0800, Nicolin Chen wrote:
> > > +int arm_vmaster_report_event(struct arm_smmu_vmaster
On Tue, Feb 25, 2025 at 12:02:25PM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 24, 2025 at 03:45:33PM -0800, Nicolin Chen wrote:
>
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
> > @@ -95,8 +95,6 @@ int arm_smmu_attach_p
On Thu, Jun 19, 2025 at 03:53:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 19, 2025 at 11:47:24AM +0000, Pranjal Shrivastava wrote:
> > I'm not sure if I get this right.. if the user (while porting a VMM or
> > something) mistakenly passes *type == IOMMU_HW_INFO
On Sat, Jun 14, 2025 at 12:14:32AM -0700, Nicolin Chen wrote:
> Now, access->ops can be NULL, to support an internal use case for the new
> HW queue object. Since an access object in this case will be allocated by
> an inernal iommufd object, the refcount on the ictx should be skipped, so
> as not
On Mon, Jun 16, 2025 at 07:25:57PM -0700, Nicolin Chen wrote:
> On Mon, Jun 16, 2025 at 10:37:19AM -0300, Jason Gunthorpe wrote:
> > On Sat, Jun 14, 2025 at 12:14:32AM -0700, Nicolin Chen wrote:
> > > Now, access->ops can be NULL, to support an internal use case for the new
> > > HW queue object. S
On Sat, Jun 14, 2025 at 12:14:45AM -0700, Nicolin Chen wrote:
> This will be used by Tegra241 CMDQV implementation to report a non-default
> HW info data.
>
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/
.
>
> OK. So, it probably should be
> if (IS_ENABLED(CONFIG_IOMMUFD_TEST) &&
> WARN_ON(access->iova_alignment != PAGE_SIZE ||
> (access->ictx && !access->ops->unmap))
>
Nit: Probably worth mentioning in a comment that access
e usage of mtree seems fine now, storing pfns ranges as compared to
pointers in v3. Input validation checks, vma checks and destroy op look
good.
Reviewed-by: Pranjal Shrivastava
> Reviewed-by: Kevin Tian
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/iommufd_private.h |
ommu->ops->vdevice_size;
> + }
> +
> + vdev = (struct iommufd_vdevice *)_iommufd_object_alloc_ucmd(
> + ucmd, vdev_size, IOMMUFD_OBJ_VDEVICE);
> if (IS_ERR(vdev)) {
> rc = PTR_ERR(vdev);
> goto out_put_idev;
> @@ -168,6 +186,12 @@ int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd
> *ucmd)
> goto out_put_idev;
> }
>
> + if (viommu->ops && viommu->ops->vdevice_init) {
> + rc = viommu->ops->vdevice_init(vdev);
> + if (rc)
> + goto out_put_idev;
> + }
> +
> cmd->out_vdevice_id = vdev->obj.id;
> rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
>
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
On Fri, Jun 20, 2025 at 10:36:56PM -0700, Nicolin Chen wrote:
> On Fri, Jun 20, 2025 at 03:32:19AM +0000, Pranjal Shrivastava wrote:
> > My point is that in-case someone passed INTEL_VTD type, we would end up
> > calling impl_ops->hw_info and then the impl_ops->hw_info shall c
On Thu, Jul 10, 2025 at 12:32:02PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 10, 2025 at 11:09:26AM +0000, Pranjal Shrivastava wrote:
> > On Wed, Jul 09, 2025 at 10:59:14PM -0700, Nicolin Chen wrote:
> > > Test both IOMMU_HW_INFO_TYPE_DEFAULT and IOMMU_HW_INFO_TYPE_SELFTES
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
Note: I see a couple of warnings while building the selftests on Jason's
tree, but these seem unrelated to this series:
make -C tools/testing/selftests TARGETS=iommu
make: Entering directory
'/usr/local/google/ho
On Wed, Jul 09, 2025 at 10:59:10PM -0700, Nicolin Chen wrote:
> Extend the loopback test to a new mmap page.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
> ---
> drivers/iommu/iommufd/iommufd_test.h | 4 +++
> tools/testing/selftests/iommu/io
On Wed, Jul 09, 2025 at 10:59:08PM -0700, Nicolin Chen wrote:
> Some simple tests for IOMMUFD_CMD_HW_QUEUE_ALLOC infrastructure covering
> the new iommufd_hw_queue_depend/undepend() helpers.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Pranjal Shrivastava
> ---
> dri
On Fri, Jul 04, 2025 at 09:50:12AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 03, 2025 at 06:48:42PM +0000, Pranjal Shrivastava wrote:
>
> > Ahh, thanks for this, that saved a lot of my time! And yes, I see some
> > functions in eventq.c calling the iopf_group_response
On Thu, Jul 10, 2025 at 02:12:16PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 10, 2025 at 04:43:14PM +0000, Pranjal Shrivastava wrote:
> > On Thu, Jul 10, 2025 at 12:32:02PM -0300, Jason Gunthorpe wrote:
> > Alright, this was on the `for-next` branch when
On Thu, Jul 03, 2025 at 02:55:32PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 03, 2025 at 02:46:03PM +0000, Pranjal Shrivastava wrote:
>
> > Right.. I was however hoping we'd also trap commands like CMD_PRI_RESP
> > and CMD_RESUME...I'm not sure if they should be a
On Wed, Jul 02, 2025 at 03:05:41PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 02, 2025 at 01:38:33AM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jul 01, 2025 at 05:46:06PM -0700, Nicolin Chen wrote:
> > > On Wed, Jul 02, 2025 at 12:14:28AM +, Pranjal Shrivastava wrote:
&g
On Tue, Jul 01, 2025 at 04:01:34PM -0700, Nicolin Chen wrote:
> On Tue, Jul 01, 2025 at 10:51:20PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jul 01, 2025 at 03:07:57PM -0700, Nicolin Chen wrote:
> > > On Tue, Jul 01, 2025 at 08:43:30PM +, Pranjal Shrivastava wrote:
>
On Tue, Jul 01, 2025 at 03:07:57PM -0700, Nicolin Chen wrote:
> On Tue, Jul 01, 2025 at 08:43:30PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jul 01, 2025 at 01:23:17PM -0700, Nicolin Chen wrote:
> > > Or perhaps calling them "non-accelerated commands" would be
On Tue, Jul 01, 2025 at 01:23:17PM -0700, Nicolin Chen wrote:
> On Tue, Jul 01, 2025 at 08:03:35PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jul 01, 2025 at 12:42:32PM -0700, Nicolin Chen wrote:
> > > On Tue, Jul 01, 2025 at 04:02:35PM +, Pranjal Shrivastava wrote:
>
On Tue, Jul 01, 2025 at 12:42:32PM -0700, Nicolin Chen wrote:
> On Tue, Jul 01, 2025 at 04:02:35PM +0000, Pranjal Shrivastava wrote:
> > On Thu, Jun 26, 2025 at 12:34:58PM -0700, Nicolin Chen wrote:
> > > /**
> > > * enum iommu_hw_info_type
pe
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 7 +
> include/uapi/linux/iommufd.h | 58 +++
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 6 +-
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c| 407 +-
> 4 files c
On Tue, Jul 01, 2025 at 05:46:06PM -0700, Nicolin Chen wrote:
> On Wed, Jul 02, 2025 at 12:14:28AM +0000, Pranjal Shrivastava wrote:
> > Thus, coming back to the two initial points:
> >
> > 1) Issuing "non-invalidation" commands through .cache_invalidate could
>
gt; - return ERR_PTR(-EOPNOTSUPP);
> + *type != IOMMU_HW_INFO_TYPE_ARM_SMMUV3) {
> + if (!impl_ops || !impl_ops->hw_info)
> + return ERR_PTR(-EOPNOTSUPP);
> + return impl_ops->hw_info(master->smmu, length, type);
> + }
>
> info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info)
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
->id, vdev, NULL, GFP_KERNEL);
> + xa_cmpxchg(&viommu->vdevs, vdev->virt_id, vdev, NULL, GFP_KERNEL);
> refcount_dec(&viommu->obj.users);
> put_device(vdev->dev);
> }
> @@ -150,7 +150,7 @@ int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd *ucmd)
> goto out_put_idev;
> }
>
> - vdev->id = virt_id;
> + vdev->virt_id = virt_id;
> vdev->dev = idev->dev;
> get_device(idev->dev);
> vdev->viommu = viommu;
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
f (cmd->flags & ~SUPPORTED_FLAGS)
> + return -EOPNOTSUPP;
> + if (cmd->__reserved[0] || cmd->__reserved[1] || cmd->__reserved[2])
> return -EOPNOTSUPP;
>
> /* Clear the type field since drivers don't support a random input */
> - cmd->out_data_type = IOMMU_HW_INFO_TYPE_DEFAULT;
> + if (!(cmd->flags & IOMMU_HW_INFO_FLAG_INPUT_TYPE))
> + cmd->in_data_type = IOMMU_HW_INFO_TYPE_DEFAULT;
>
> idev = iommufd_get_device(ucmd, cmd->dev_id);
> if (IS_ERR(idev))
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
est.c
> @@ -287,7 +287,8 @@ static struct iommu_domain mock_blocking_domain = {
> .ops = &mock_blocking_ops,
> };
>
> -static void *mock_domain_hw_info(struct device *dev, u32 *length, u32 *type)
> +static void *mock_domain_hw_info(struct device *dev, u32 *length,
> + enum iommu_hw_info_type *type)
> {
> struct iommu_test_hw_info *info;
>
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
> return PTR_ERR(idev);
> diff --git a/drivers/iommu/iommufd/selftest.c
> b/drivers/iommu/iommufd/selftest.c
> index 8b2c44b32530..a5dc36219a90 100644
> --- a/drivers/iommu/iommufd/selftest.c
> +++ b/drivers/iommu/iommufd/selftest.c
> @@ -310,6 +310,10 @@ static void *mock_do
est.c
> @@ -287,7 +287,8 @@ static struct iommu_domain mock_blocking_domain = {
> .ops = &mock_blocking_ops,
> };
>
> -static void *mock_domain_hw_info(struct device *dev, u32 *length, u32 *type)
> +static void *mock_domain_hw_info(struct device *dev, u32 *length,
> + enum iommu_hw_info_type *type)
> {
> struct iommu_test_hw_info *info;
>
Reviewed-by: Pranjal Shrivastava
> --
> 2.43.0
>
73 matches
Mail list logo
