[RFC][DISCUSSION] dma-mapping: allocating noncoherent buffer without mapping

[RFC][DISCUSSION] dma-mapping: allocating noncoherent buffer without mapping

[Hyeonggon Yoo]

Last month we discussed drivers that uses kmalloc(GFP_DMA) for 
noncoherent mapping should be converted to use DMA API [1]. Simple
grep with GFP_DMA shows that many of drivers are mistakenly
using GFP_DMA flag.

So our purpose was to make DMA API choose right zone depending on
device's dma mask. Baoquan and I are trying to make drivers to
use dma_alloc_noncoherent() when allocating the buffer.

But it's not simple for some of drivers; there is a gap between
dma_alloc_noncoherent() and the previous convention (allocating buffer
from buddy or slab allocator and mapping it when needed.)

For example, some drivers allocate buffer and reuse it. it just maps
and unmaps whenever needed. And some drivers does not even maps the
buffer. (some drivers that does not use DMA API)

So I think we need to implement a version of dma_alloc_noncoherent()
that does not map the buffer.

I think implementing a helper that internally calls
__dma_direct_alloc_pages() will be okay.

As I'm not expert in this area, I want to hear
others' opinions.

[1] https://lkml.org/lkml/2021/12/13/1121

Thanks,
Hyeonggon.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC][DISCUSSION] dma-mapping: allocating noncoherent buffer without mapping

[Robin Murphy]

On 2022-01-26 11:54, Hyeonggon Yoo wrote:
> Last month we discussed drivers that uses kmalloc(GFP_DMA) for
> noncoherent mapping should be converted to use DMA API [1]. Simple
> grep with GFP_DMA shows that many of drivers are mistakenly
> using GFP_DMA flag.
> 
> So our purpose was to make DMA API choose right zone depending on
> device's dma mask. Baoquan and I are trying to make drivers to
> use dma_alloc_noncoherent() when allocating the buffer.
> 
> But it's not simple for some of drivers; there is a gap between
> dma_alloc_noncoherent() and the previous convention (allocating buffer
> from buddy or slab allocator and mapping it when needed.)
> 
> For example, some drivers allocate buffer and reuse it. it just maps
> and unmaps whenever needed. And some drivers does not even maps the
> buffer. (some drivers that does not use DMA API)
> 
> So I think we need to implement a version of dma_alloc_noncoherent()
> that does not map the buffer.

This doesn't make sense to me. The point of dma_alloc_* is you get back 
a dedicated DMA buffer which can then be used at any time. In the 
noncoherent case you have to put in explicit dma_sync_*() calls around 
accesses when the CPU or device is expected to have updated the buffer 
contents, but it's still fundamentally the same paradigm.

If you want to update drivers from using streaming mappings on 
specially-allocated pages to using proper dedicated DMA buffers, then 
update the logic in those drivers to use dedicated DMA buffers 
appropriately. Adding an API to allocate a DMA buffer which isn't 
actually a DMA buffer so we can "update" drivers from misusing streaming 
mappings to still misusing streaming mappings is nonsense.

Robin.

> I think implementing a helper that internally calls
> __dma_direct_alloc_pages() will be okay.
> 
> As I'm not expert in this area, I want to hear
> others' opinions.
> 
> [1] https://lkml.org/lkml/2021/12/13/1121
> 
> Thanks,
> Hyeonggon.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC][DISCUSSION] dma-mapping: allocating noncoherent buffer without mapping

[Christoph Hellwig]

On Wed, Jan 26, 2022 at 01:08:04PM +0000, Robin Murphy wrote:
> This doesn't make sense to me. The point of dma_alloc_* is you get back a 
> dedicated DMA buffer which can then be used at any time. In the noncoherent 
> case you have to put in explicit dma_sync_*() calls around accesses when 
> the CPU or device is expected to have updated the buffer contents, but it's 
> still fundamentally the same paradigm.

Exactly.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu