diff options
author | Leon Romanovsky <leon@kernel.org> | 2025-05-12 05:04:15 -0400 |
---|---|---|
committer | Leon Romanovsky <leon@kernel.org> | 2025-05-12 05:04:15 -0400 |
commit | 972aa49a7c93fecdf281d2a7f4914085f3b327eb (patch) | |
tree | a5f3e84e5dddfcbf10867bf025590bd70a846dea /scripts/gdb/linux/utils.py | |
parent | 4ffb62fa8925c1c1591145ff0f5ccfd5918b40df (diff) | |
parent | 3ee7d9496342246f4353716f6bbf64c945ff6e2d (diff) |
Provide a new two step DMA mapping API
Currently the only efficient way to map a complex memory description through
the DMA API is by using the scatter list APIs. The SG APIs are unique in that
they efficiently combine the two fundamental operations of sizing and allocating
a large IOVA window from the IOMMU and processing all the per-address
swiotlb/flushing/p2p/map details.
This uniqueness has been a long standing pain point as the scatter list API
is mandatory, but expensive to use. It prevents any kind of optimization or
feature improvement (such as avoiding struct page for P2P) due to the
impossibility of improving the scatter list.
Several approaches have been explored to expand the DMA API with additional
scatterlist-like structures (BIO, rlist), instead split up the DMA API
to allow callers to bring their own data structure.
The API is split up into parts:
- Allocate IOVA space:
To do any pre-allocation required. This is done based on the caller
supplying some details about how much IOMMU address space it would need
in worst case.
- Map and unmap relevant structures to pre-allocated IOVA space:
Perform the actual mapping into the pre-allocated IOVA. This is very
similar to dma_map_page().
Thanks
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/utils.py')
0 files changed, 0 insertions, 0 deletions