On Tue, 21 Apr 2026 09:10:04 -0300 Jason Gunthorpe jgg@ziepe.ca wrote:
On Tue, Apr 21, 2026 at 01:53:31PM +0200, Jiri Pirko wrote:
You reach there when is_swiotlb_force_bounce(dev) is true and DMA_ATTR_CC_SHARED is set. What am I missing?
So a swiotlb_force_bounce will not use swiotlb bouncing if DMA_ATTR_CC_SHARED is set ?
Correct. Bouncing does not make sense in this case, as shared memory is already being mapped.
It is a little bit mangled, there are many reasons force_swiotlb can be set, but we loose them as it flows through - swiotlb_init() just has a simple SWIOTLB_FORCE
Ideally DMA_ATTR_CC_SHARED would skip swiotlb only if it is being selected for CC reasons. For instance if you have the swiotlb force command line parameter I would still expect it bounce shared memory.
Arguably I think this arch flow is misdesigned, the is_swiotlb_force_bounce() should not be used for CC. dma_capable() is the correct API to check if the device can DMA to the presented address, and it will trigger swiotlb_map() just the same without creating this gap.
Seconded.
Then again, the whole DMA mapping logic is extremely convoluted, with dmaops, direct, CMA, and swiotlb, so I'm no longer sure there is one undisputable way where CC shared mappings should be added to the mix.
Has anyone considered a cleaner design yet? If yes, I'm volunteering to help implement it. If not, then please ignore me as a random rant.
Petr T