summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorLeon Romanovsky <leonro@nvidia.com>2026-03-16 21:06:52 +0200
committerMarek Szyprowski <m.szyprowski@samsung.com>2026-03-20 12:05:56 +0100
commitf5ebf241c407dbf629fcf515015e139fcea2c2f0 (patch)
treeb670a7dfc2f81c3a95433ec082ffd1e52388ccbd /kernel
parentd9d43a3f5c48d5a3d1da922f46c4a30d94d61ba5 (diff)
mm/hmm: Indicate that HMM requires DMA coherency
HMM is fundamentally about allowing a sophisticated device to perform DMA directly to a process’s memory while the CPU accesses that same memory at the same time. It is similar to SVA but does not rely on IOMMU support. Because the entire model depends on concurrent access to shared memory, it fails as a uAPI if SWIOTLB substitutes the memory or if the CPU caches are not coherent with DMA. Until now, there has been no reliable way to report this, and various approximations have been used: int hmm_dma_map_alloc(struct device *dev, struct hmm_dma_map *map, size_t nr_entries, size_t dma_entry_size) { <...> /* * The HMM API violates our normal DMA buffer ownership rules and can't * transfer buffer ownership. The dma_addressing_limited() check is a * best approximation to ensure no swiotlb buffering happens. */ dma_need_sync = !dev->dma_skip_sync; if (dma_need_sync || dma_addressing_limited(dev)) return -EOPNOTSUPP; So let's mark mapped buffers with DMA_ATTR_REQUIRE_COHERENT attribute to prevent silent data corruption if someone tries to use hmm in a system with swiotlb or incoherent DMA Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260316-dma-debug-overlap-v3-8-1dde90a7f08b@nvidia.com
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions