[PATCH v6 0/5] iommufd: Iterate the cache invalidation array in the core

Nicolin Chen posted 5 patches 3 weeks, 5 days ago
include/linux/iommu.h                         |   6 +-
include/linux/iommufd.h                       |   2 +
include/uapi/linux/iommufd.h                  |   4 +-
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c     | 197 ++++++++++++++----
drivers/iommu/intel/nested.c                  |  54 ++---
drivers/iommu/iommufd/hw_pagetable.c          |  25 ++-
drivers/iommu/iommufd/selftest.c              | 147 +++++++------
7 files changed, 282 insertions(+), 153 deletions(-)
[PATCH v6 0/5] iommufd: Iterate the cache invalidation array in the core
Posted by Nicolin Chen 3 weeks, 5 days ago
The vIOMMU cache_invalidate() and the nested-HWPT cache_invalidate_user()
ops are each handed the full user invalidation array and must report, via
array->entry_num, how many of its entries they handled. That makes every
driver open-code the same array walk, with real downsides:

 - each driver carries its own loop and sub-array bookkeeping;
 - the ARM SMMUv3 driver allocates a buffer sized to the whole array just
   to iterate over it;
 - hand-rolling the loop left the ARM SMMUv3 driver with two long-standing
   bugs:
    1) on a conversion failure it counts commands that it converted but
       never issued, so user space skips invalidations that never reached
       the cmdq;
    2) it rejects a zero-length array, which the uAPI documents as a valid
       request that only probes the data type.

The walk is identical for every driver, so move it into the iommufd core.

The core now drives the iteration:

 - it invokes the op on a sub-array starting at the first not-yet-handled
   entry;
 - the op handles one chunk from the front of that sub-array and reports
   the count via array->entry_num;
 - the core advances and re-invokes until the whole array is consumed or
   the op returns an error.

A driver then only has to handle one bounded chunk per call, e.g. the ARM
SMMUv3 op copies a single cmdq batch into a fixed on-stack buffer and drops
its whole-array allocation. An op still handling the entire array in one
call keeps working, so each driver converts independently.

All the bugs fixed here are long-standing ones rather than regressions in
this cycle, so the series targets for-next, not for-rc. The stable tag on
the second patch takes care of the backport.

This is on Github:
https://github.com/nicolinc/iommufd/commits/iommufd_invalidation_loop-v6

Changelog
v6
 * Rebase on top of v7.3-rc1
 * Drop the merged IDR5.DS patch
v5
 https://lore.kernel.org/all/cover.1785258826.git.nicolinc@nvidia.com/
 * Rebase on top of arm/smmu/updates branch
 * Add "Reviewed-by" from Jason and Pranjal
 * Patch-1: Drop the Fixes and Cc stable tags
 * Patch-2: Reject an unsupported opcode in the validation helper
 * Patch-2: Add an explicit NSNH_ALL case to the allowlist switch
v4
 https://lore.kernel.org/all/cover.1784054606.git.nicolinc@nvidia.com/
 * Add "Reviewed-by" from Baolu and Pranjal
 * Split the DS support out of the reject patch into a new patch-1,
   also listing DS in the iommu_hw_info_arm_smmuv3 kdoc
 * Patch-2: Add "!!" to the bool range assignment
 * Patch-2: Factor the allowlist into arm_vsmmu_validate_user_cmd()
v3
 https://lore.kernel.org/all/cover.1783539724.git.nicolinc@nvidia.com/
 * Patch-1: Add a minimal FEAT_DS detection and allow the two DS-only
   range encodings on a DS-capable SMMU
 * Patch-1: Mask the host's scale value to keep its 5-bit truncation
v2
 https://lore.kernel.org/all/cover.1783363477.git.nicolinc@nvidia.com/
 * Add "Reviewed-by" from Kevin to patches 2-5
 * Patch-1: Allow the ATC_INV Global bit gated on ssid_bits, correcting
   the wrong every-device claim: per the spec it only broadens a single
   device's invalidation across its PASIDs
 * Patch-1: Move the FEAT_ATS check into the allowlist switch
 * Patch-1: Gate the TTL range field on FEAT_RANGE_INV too
 * Patch-1: Accept only asid_bits of the ASID field
 * Patch-1: Reject Reserved range field value combinations
 * Patch-1: Reject an ATC_INV Size above 52
 * Patch-1: Add local smmu and data variables to simplify the long lines
 * Patch-1: Document the valid-command contract in the uAPI header
 * Patch-1: Note that unchecked out-of-range values are UNPREDICTABLE
 * Patch-1: Note that SSID/Global are IGNORED, not RES0, when SSV == 0
 * Patch-2: Consolidate the two invalidation loops into one
 * Patch-2: Multiply by the size_t entry_len to avoid a u32 overflow
 * Patch-3/5: Return 0 directly on a zero-length array
 * Patch-4: Use a processed counter and an out label like the mock driver
v1
 https://lore.kernel.org/all/cover.1782767398.git.nicolinc@nvidia.com/


Nicolin Chen (5):
  iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation
    commands
  iommufd: Iterate the cache invalidation array in the core
  iommufd/selftest: Convert cache invalidation mocks to the core array
    loop
  iommu/arm-smmu-v3-iommufd: Convert cache invalidation to the core
    array loop
  iommu/vt-d: Convert nested cache invalidation to the core array loop

 include/linux/iommu.h                         |   6 +-
 include/linux/iommufd.h                       |   2 +
 include/uapi/linux/iommufd.h                  |   4 +-
 .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c     | 197 ++++++++++++++----
 drivers/iommu/intel/nested.c                  |  54 ++---
 drivers/iommu/iommufd/hw_pagetable.c          |  25 ++-
 drivers/iommu/iommufd/selftest.c              | 147 +++++++------
 7 files changed, 282 insertions(+), 153 deletions(-)


base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
-- 
2.43.0
Re: [PATCH v6 0/5] iommufd: Iterate the cache invalidation array in the core
Posted by Jason Gunthorpe 2 weeks, 3 days ago
On Sun, Aug 30, 2026 at 03:26:37PM -0700, Nicolin Chen wrote:
> The vIOMMU cache_invalidate() and the nested-HWPT cache_invalidate_user()
> ops are each handed the full user invalidation array and must report, via
> array->entry_num, how many of its entries they handled. That makes every
> driver open-code the same array walk, with real downsides:
[..]
> Nicolin Chen (5):
>   iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation
>     commands
>   iommufd: Iterate the cache invalidation array in the core
>   iommufd/selftest: Convert cache invalidation mocks to the core array
>     loop
>   iommu/arm-smmu-v3-iommufd: Convert cache invalidation to the core
>     array loop
>   iommu/vt-d: Convert nested cache invalidation to the core array loop
> 
>  include/linux/iommu.h                         |   6 +-
>  include/linux/iommufd.h                       |   2 +
>  include/uapi/linux/iommufd.h                  |   4 +-
>  .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c     | 197 ++++++++++++++----
>  drivers/iommu/intel/nested.c                  |  54 ++---
>  drivers/iommu/iommufd/hw_pagetable.c          |  25 ++-
>  drivers/iommu/iommufd/selftest.c              | 147 +++++++------
>  7 files changed, 282 insertions(+), 153 deletions(-)

Will, can I pick this up, or did you want a branch or something?

Thanks,
Jason
Re: [PATCH v6 0/5] iommufd: Iterate the cache invalidation array in the core
Posted by Will Deacon 2 weeks, 2 days ago
On Wed, Sep 09, 2026 at 01:41:07PM -0300, Jason Gunthorpe wrote:
> On Sun, Aug 30, 2026 at 03:26:37PM -0700, Nicolin Chen wrote:
> > The vIOMMU cache_invalidate() and the nested-HWPT cache_invalidate_user()
> > ops are each handed the full user invalidation array and must report, via
> > array->entry_num, how many of its entries they handled. That makes every
> > driver open-code the same array walk, with real downsides:
> [..]
> > Nicolin Chen (5):
> >   iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation
> >     commands
> >   iommufd: Iterate the cache invalidation array in the core
> >   iommufd/selftest: Convert cache invalidation mocks to the core array
> >     loop
> >   iommu/arm-smmu-v3-iommufd: Convert cache invalidation to the core
> >     array loop
> >   iommu/vt-d: Convert nested cache invalidation to the core array loop
> > 
> >  include/linux/iommu.h                         |   6 +-
> >  include/linux/iommufd.h                       |   2 +
> >  include/uapi/linux/iommufd.h                  |   4 +-
> >  .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c     | 197 ++++++++++++++----
> >  drivers/iommu/intel/nested.c                  |  54 ++---
> >  drivers/iommu/iommufd/hw_pagetable.c          |  25 ++-
> >  drivers/iommu/iommufd/selftest.c              | 147 +++++++------
> >  7 files changed, 282 insertions(+), 153 deletions(-)
> 
> Will, can I pick this up, or did you want a branch or something?

All yours!

Will
Re: [PATCH v6 0/5] iommufd: Iterate the cache invalidation array in the core
Posted by Jason Gunthorpe 2 weeks, 1 day ago
On Sun, 30 Aug 2026 15:26:37 -0700, Nicolin Chen wrote:
> iommufd: Iterate the cache invalidation array in the core
> 
> The vIOMMU cache_invalidate() and the nested-HWPT cache_invalidate_user()
> ops are each handed the full user invalidation array and must report, via
> array->entry_num, how many of its entries they handled. That makes every
> driver open-code the same array walk, with real downsides:
> 
> [...]

Applied, thanks!

[1/5] iommu/arm-smmu-v3-iommufd: Reject unsupported bits in invalidation commands
      https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/commit/?id=26564d25cd814dfd72a21a2c52b81e678cf02bae
[2/5] iommufd: Iterate the cache invalidation array in the core
      https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/commit/?id=61e2f25a49bc4d274e71856b2bcac0753f38bafb
[3/5] iommufd/selftest: Convert cache invalidation mocks to the core array loop
      https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/commit/?id=5519695903a4b443903dd6d9207ad340bc3c984b
[4/5] iommu/arm-smmu-v3-iommufd: Convert cache invalidation to the core array loop
      https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/commit/?id=2d4f03f6610d569070a86d8d2c583ddfcd390f75
[5/5] iommu/vt-d: Convert nested cache invalidation to the core array loop
      https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/commit/?id=fe85c40e992be9578b8cdfa992d9e23005e25e77

Best regards,
-- 
Jason