On Sun, Mar 08, 2026 at 08:09:16PM -0300, Jason Gunthorpe wrote: > On Sun, Mar 08, 2026 at 08:49:02PM +0200, Leon Romanovsky wrote: > > On Sun, Mar 08, 2026 at 03:19:20PM -0300, Jason Gunthorpe wrote: > > > On Sat, Mar 07, 2026 at 06:49:56PM +0200, Leon Romanovsky wrote: > > > > > > > -This attribute indicates the CPU will not dirty any cacheline > > > > overlapping this > > > > -DMA_FROM_DEVICE/DMA_BIDIRECTIONAL buffer while it is mapped. This > > > > allows > > > > -multiple small buffers to safely share a cacheline without risk of data > > > > -corruption, suppressing DMA debug warnings about overlapping mappings. > > > > -All mappings sharing a cacheline should have this attribute. > > > > +DMA_ATTR_CPU_CACHE_OVERLAP > > > > > > This is a very specific and well defined use case that allows some cache > > > flushing behaviors to work only under the promise that the CPU doesn't > > > touch the memory to cause cache inconsistencies. > > > > > > > +Another valid use case is on systems that are CPU-coherent and do not > > > > use > > > > +SWIOTLB, where the caller can guarantee that no cache maintenance > > > > operations > > > > +(such as flushes) will be performed that could overwrite shared cache > > > > lines. > > > > > > This is something completely unrelated. > > > > I disagree. The situation is equivalent in that callers guarantee the > > CPU cache will not be overwritten. > > The RDMA callers do no such thing, they just don't work at all if > there is non-coherence in the mapping which is why it is not a bug. > > virtio looks like it does actually keep the caches clean for different > mappings (and probably also in practice forced coherent as well given > qemu is coherent with the VM and VFIO doesn't allow non-coherent DMA > devices) > > > > What I would really like is a new DMA_ATTR_REQUIRE_COHERENT which > > > fails any mappings requests that would use any SWIOTLB or cache > > > flushing. > > > > You are proposing something orthogonal that operates at a different layer > > (DMA mapping). However, for DMA debugging, your new attribute will be > > equivalent to DMA_ATTR_CPU_CACHE_OVERLAP. > > DMA_ATTR is a dma mapping flag, if you want some weird dma debugging > flag it should be called DMA_ATTR_DEBUGGING_IGNORE_CACHELINES with > some kind of statement at the user why it is OK.
And this is the issue: the existing DMA_ATTR_CPU_CACHE_CLEAN is essentially a debug-oriented attribute. The upper layers are already handled through __dma_from_device_group_begin()/end(), which pad cache lines on non-coherent systems. Marek, What do you see as the right path forward here? RDMA has a legitimate use case where CPU cache lines may overlap. The underlying reason differs from VirtIO, but the outcome is the same. Should I keep the current name? Should we rename it to the proposed DMA_ATTR_CPU_CACHE_OVERLAP or DMA_ATTR_DEBUGGING_IGNORE_CACHELINES? Should we introduce a new DMA_ATTR_REQUIRE_COHERENT attribute instead? Or do you have another recommendation? Thanks > > Jason
