Re: [RFC RESEND 00/16] Split IOMMU DMA mapping operation to two steps
From: Zhu Yanjun
Date: Fri May 03 2024 - 07:57:22 EST
On 03.05.24 01:32, Zeng, Oak wrote:
Hi Leon, Jason
-----Original Message-----
From: Leon Romanovsky <leon@xxxxxxxxxx>
Sent: Tuesday, March 5, 2024 6:19 AM
To: Christoph Hellwig <hch@xxxxxx>; Robin Murphy
<robin.murphy@xxxxxxx>; Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx>; Joerg Roedel <joro@xxxxxxxxxx>; Will
Deacon <will@xxxxxxxxxx>; Jason Gunthorpe <jgg@xxxxxxxx>; Chaitanya
Kulkarni <chaitanyak@xxxxxxxxxx>
Cc: Jonathan Corbet <corbet@xxxxxxx>; Jens Axboe <axboe@xxxxxxxxx>;
Keith Busch <kbusch@xxxxxxxxxx>; Sagi Grimberg <sagi@xxxxxxxxxxx>;
Yishai Hadas <yishaih@xxxxxxxxxx>; Shameer Kolothum
<shameerali.kolothum.thodi@xxxxxxxxxx>; Kevin Tian
<kevin.tian@xxxxxxxxx>; Alex Williamson <alex.williamson@xxxxxxxxxx>;
Jérôme Glisse <jglisse@xxxxxxxxxx>; Andrew Morton <akpm@linux-
foundation.org>; linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
linux-block@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx;
iommu@xxxxxxxxxxxxxxx; linux-nvme@xxxxxxxxxxxxxxxxxxx;
kvm@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; Bart Van Assche
<bvanassche@xxxxxxx>; Damien Le Moal
<damien.lemoal@xxxxxxxxxxxxxxxxxx>; Amir Goldstein
<amir73il@xxxxxxxxx>; josef@xxxxxxxxxxxxxx; Martin K. Petersen
<martin.petersen@xxxxxxxxxx>; daniel@xxxxxxxxxxxxx; Dan Williams
<dan.j.williams@xxxxxxxxx>; jack@xxxxxxxx; Leon Romanovsky
<leonro@xxxxxxxxxx>; Zhu Yanjun <zyjzyj2000@xxxxxxxxx>
Subject: [RFC RESEND 00/16] Split IOMMU DMA mapping operation to two
steps
This is complimentary part to the proposed LSF/MM topic.
https://lore.kernel.org/linux-rdma/22df55f8-cf64-4aa8-8c0b-
b556c867b926@xxxxxxxxx/T/#m85672c860539fdbbc8fe0f5ccabdc05b40269057
This is posted as RFC to get a feedback on proposed split, but RDMA, VFIO
and
DMA patches are ready for review and inclusion, the NVMe patches are still
in
progress as they require agreement on API first.
Thanks
-------------------------------------------------------------------------------
The DMA mapping operation performs two steps at one same time: allocates
IOVA space and actually maps DMA pages to that space. This one shot
operation works perfectly for non-complex scenarios, where callers use
that DMA API in control path when they setup hardware.
However in more complex scenarios, when DMA mapping is needed in data
path and especially when some sort of specific datatype is involved,
such one shot approach has its drawbacks.
That approach pushes developers to introduce new DMA APIs for specific
datatype. For example existing scatter-gather mapping functions, or
latest Chuck's RFC series to add biovec related DMA mapping [1] and
probably struct folio will need it too.
These advanced DMA mapping APIs are needed to calculate IOVA size to
allocate it as one chunk and some sort of offset calculations to know
which part of IOVA to map.
Instead of teaching DMA to know these specific datatypes, let's separate
existing DMA mapping routine to two steps and give an option to advanced
callers (subsystems) perform all calculations internally in advance and
map pages later when it is needed.
I looked into how this scheme can be applied to DRM subsystem and GPU drivers.
I figured RDMA can apply this scheme because RDMA can calculate the iova size. Per my limited knowledge of rdma, user can register a memory region (the reg_user_mr vfunc) and memory region's sized is used to pre-allocate iova space. And in the RDMA use case, it seems the user registered region can be very big, e.g., 512MiB or even GiB
In GPU driver, we have a few use cases where we need dma-mapping. Just name two:
1) userptr: it is user malloc'ed/mmap'ed memory and registers to gpu (in Intel's driver it is through a vm_bind api, similar to mmap). A userptr can be of any random size, depending on user malloc size. Today we use dma-map-sg for this use case. The down side of our approach is, during userptr invalidation, even if user only munmap partially of an userptr, we invalidate the whole userptr from gpu page table, because there is no way for us to partially dma-unmap the whole sg list. I think we can try your new API in this case. The main benefit of the new approach is the partial munmap case.
We will have to pre-allocate iova for each userptr, and we have many userptrs of random size... So we might be not as efficient as RDMA case where I assume user register a few big memory regions.
2) system allocator: it is malloc'ed/mmap'ed memory be used for GPU program directly, without any other extra driver API call. We call this use case system allocator.
For system allocator, driver have no knowledge of which virtual address range is valid in advance. So when GPU access a malloc'ed/mmap'ed address, we have a page fault. We then look up a CPU vma which contains the fault address. I guess we can use the CPU vma size to allocate the iova space of the same size?
But there will be a true difficulty to apply your scheme to this use case. It is related to the STICKY flag. As I understand it, the sticky flag is designed for driver to mark "this page/pfn has been populated, no need to re-populate again", roughly...Unlike userptr and RDMA use cases where the backing store of a buffer is always in system memory, in the system allocator use case, the backing store can be changing b/t system memory and GPU's device private memory. Even worse, we have to assume the data migration b/t system and GPU is dynamic. When data is migrated to GPU, we don't need dma-map. And when migration happens to a pfn with STICKY flag, we still need to repopulate this pfn. So you can see, it is not easy to apply this scheme to this use case. At least I can't see an obvious way.
Not sure if GPU peer to peer dma mapping GPU memory for use can use this
scheme or not. If I remember it correctly, Intel Gaudi GPU supports peer
2 peer dma mapping in GPU Direct RDMA. Not sure if this scheme can be
applied in that place or not.
Just my 2 cent suggestions.
Zhu Yanjun
Oak
In this series, three users are converted and each of such conversion
presents different positive gain:
1. RDMA simplifies and speeds up its pagefault handling for
on-demand-paging (ODP) mode.
2. VFIO PCI live migration code saves huge chunk of memory.
3. NVMe PCI avoids intermediate SG table manipulation and operates
directly on BIOs.
Thanks
[1]
https://lore.kernel.org/all/169772852492.5232.17148564580779995849.stgit@
klimt.1015granger.net
Chaitanya Kulkarni (2):
block: add dma_link_range() based API
nvme-pci: use blk_rq_dma_map() for NVMe SGL
Leon Romanovsky (14):
mm/hmm: let users to tag specific PFNs
dma-mapping: provide an interface to allocate IOVA
dma-mapping: provide callbacks to link/unlink pages to specific IOVA
iommu/dma: Provide an interface to allow preallocate IOVA
iommu/dma: Prepare map/unmap page functions to receive IOVA
iommu/dma: Implement link/unlink page callbacks
RDMA/umem: Preallocate and cache IOVA for UMEM ODP
RDMA/umem: Store ODP access mask information in PFN
RDMA/core: Separate DMA mapping to caching IOVA and page linkage
RDMA/umem: Prevent UMEM ODP creation with SWIOTLB
vfio/mlx5: Explicitly use number of pages instead of allocated length
vfio/mlx5: Rewrite create mkey flow to allow better code reuse
vfio/mlx5: Explicitly store page list
vfio/mlx5: Convert vfio to use DMA link API
Documentation/core-api/dma-attributes.rst | 7 +
block/blk-merge.c | 156 ++++++++++++++
drivers/infiniband/core/umem_odp.c | 219 +++++++------------
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
drivers/infiniband/hw/mlx5/odp.c | 59 +++--
drivers/iommu/dma-iommu.c | 129 ++++++++---
drivers/nvme/host/pci.c | 220 +++++--------------
drivers/vfio/pci/mlx5/cmd.c | 252 ++++++++++++----------
drivers/vfio/pci/mlx5/cmd.h | 22 +-
drivers/vfio/pci/mlx5/main.c | 136 +++++-------
include/linux/blk-mq.h | 9 +
include/linux/dma-map-ops.h | 13 ++
include/linux/dma-mapping.h | 39 ++++
include/linux/hmm.h | 3 +
include/rdma/ib_umem_odp.h | 22 +-
include/rdma/ib_verbs.h | 54 +++++
kernel/dma/debug.h | 2 +
kernel/dma/direct.h | 7 +-
kernel/dma/mapping.c | 91 ++++++++
mm/hmm.c | 34 +--
20 files changed, 870 insertions(+), 605 deletions(-)
--
2.44.0
--
Best Regards,
Yanjun.Zhu