On Fri, Feb 28, 2025 at 07:54:11PM +0000, Robin Murphy wrote:

On 20/02/2025 12:48 pm, Leon Romanovsky wrote:

quoted

On Wed, Feb 05, 2025 at 04:40:20PM +0200, Leon Romanovsky wrote:

quoted

From: Leon Romanovsky <leonro@nvidia.com>

Changelog:
v7:
  * Rebased to v6.14-rc1

<...>

quoted

Christoph Hellwig (6):
   PCI/P2PDMA: Refactor the p2pdma mapping helpers
   dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h
   iommu: generalize the batched sync after map interface
   iommu/dma: Factor out a iommu_dma_map_swiotlb helper
   dma-mapping: add a dma_need_unmap helper
   docs: core-api: document the IOVA-based API

Leon Romanovsky (11):
   iommu: add kernel-doc for iommu_unmap and iommu_unmap_fast
   dma-mapping: Provide an interface to allow allocate IOVA
   dma-mapping: Implement link/unlink ranges API
   mm/hmm: let users to tag specific PFN with DMA mapped bit
   mm/hmm: provide generic DMA managing logic
   RDMA/umem: Store ODP access mask information in PFN
   RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page
     linkage
   RDMA/umem: Separate implicit ODP initialization from explicit ODP
   vfio/mlx5: Explicitly use number of pages instead of allocated length
   vfio/mlx5: Rewrite create mkey flow to allow better code reuse
   vfio/mlx5: Enable the DMA link API

  Documentation/core-api/dma-api.rst   |  70 ++++

  drivers/infiniband/core/umem_odp.c   | 250 +++++---------

quoted

  drivers/infiniband/hw/mlx5/mlx5_ib.h |  12 +-
  drivers/infiniband/hw/mlx5/odp.c     |  65 ++--
  drivers/infiniband/hw/mlx5/umr.c     |  12 +-
  drivers/iommu/dma-iommu.c            | 468 +++++++++++++++++++++++----
  drivers/iommu/iommu.c                |  84 ++---
  drivers/pci/p2pdma.c                 |  38 +--
  drivers/vfio/pci/mlx5/cmd.c          | 375 +++++++++++----------
  drivers/vfio/pci/mlx5/cmd.h          |  35 +-
  drivers/vfio/pci/mlx5/main.c         |  87 +++--
  include/linux/dma-map-ops.h          |  54 ----
  include/linux/dma-mapping.h          |  85 +++++
  include/linux/hmm-dma.h              |  33 ++
  include/linux/hmm.h                  |  21 ++
  include/linux/iommu.h                |   4 +
  include/linux/pci-p2pdma.h           |  84 +++++
  include/rdma/ib_umem_odp.h           |  25 +-
  kernel/dma/direct.c                  |  44 +--
  kernel/dma/mapping.c                 |  18 ++
  mm/hmm.c                             | 264 +++++++++++++--
  21 files changed, 1435 insertions(+), 693 deletions(-)
  create mode 100644 include/linux/hmm-dma.h

Kind reminder.

...that you've simply reposted the same thing again? Without doing anything
to address the bugs, inconsistencies, fundamental design flaws in claiming
to be something it cannot possibly be, the egregious abuse of
DMA_ATTR_SKIP_CPU_SYNC proudly highlighting how unfit-for-purpose the most
basic part of the whole idea is, nor *still* the complete lack of any
demonstrable justification of how callers who supposedly can't use the IOMMU
API actually benefit from adding all the complexity of using the IOMMU API
in a hat but also still the streaming DMA API as well?

Can you please provide concrete list of "the bugs, inconsistencies, fundamental
design flaws", so we can address/fix them?

We are in v7 now and out of all postings you replied to v1 and v5 only with
followups from three of us (Christoph, Jason and me).

Yeah, consider me reminded.

Silence means agreement.

In case I need to make it any more explicit, NAK to this not-generic
not-DMA-mapping API, until you can come up with either something which *can*
actually work in any kind of vaguely generic manner as claimed, or instead
settle on a reasonable special-case solution for justifiable special cases.
Bikeshedding and rebasing through half a dozen versions, while ignoring
fundamental issues I've been pointing out from the very beginning, has not
somehow magically made this series mature and acceptable to merge.

You never responded to Christoph's answers, so please try your best and
be professional, write down the list of things you want to see handled
in next version and it will be done. It is impossible to guess what you
want if you are not saying it clearly.

The main issue which we are trying to solve "abuse of SG lists for
things without struct page", is not going to disappear by itself.

Honestly, given certain other scenarios we may also end up having to deal
with, if by the time everything broken is taken away, it were to end up
stripped all the way back to something well-reasoned like:

"Some drivers want more control of their DMA buffer layout than the
general-purpose IOVA allocator is able to provide though the DMA mapping
APIs, but also would rather not have to deal with managing an entire IOMMU
domain and address space, making MSIs work, etc. Expose
iommu_dma_alloc_iova() and some trivial IOMMU API wrappers to allow drivers
of coherent devices to claim regions of the default domain wherein they can
manage their own mappings directly."

...I wouldn't necessarily disagree.

Something like that was done in first RFC version, but the overall
feeling was that it is layer violation with unclear path to support
swiotlb for NVMe.

Thanks

Thanks,
Robin.