Question: Does dma_alloc_coherent have problem?

On arm64, invoke dma_alloc_coherent will indirect call swiotlb_alloc_coherent. The latter function allocates memory by __get_free_pages or from swiotlb buffer, then use function phys_to_dma to get iova.

static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)

{
	return (dma_addr_t)paddr;
}

But dma_alloc_coherent have not use iommu_map or other functions to create mapping between iova and pa. I known that SMMUv2 support bypass mode, so there is no problem in this case. But, some device drivers need use SMMU page table to create exact mapping, to enhance security.

And I saw that: on X86, intel_alloc_coherent manages iova address space of each iommu_group, and create mapping between iova and pa when needed.

So, I think create mapping should be done in dma_alloc_coherent.

Quoted 14 lines · leizhen

On arm64, invoke dma_alloc_coherent will indirect call swiotlb_alloc_coherent. The latter function allocates memory by __get_free_pages or from swiotlb buffer, then use function phys_to_dma to get iova.

static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)

{
	return (dma_addr_t)paddr;
}

But dma_alloc_coherent have not use iommu_map or other functions to create mapping between iova and pa. I known that SMMUv2 support bypass mode, so there is no problem in this case. But, some device drivers need use SMMU page table to create exact mapping, to enhance security.

Quoted 4 lines

And I saw that: on X86, intel_alloc_coherent manages iova address space of each iommu_group, and create mapping between iova and pa when needed.

So, I think create mapping should be done in dma_alloc_coherent.

The swiotlb, as the name implies, is for software tlbs. IOW, nothing to do with the IOMMU.

We need separate dma_ops for IOMMU which are not implemented on arm64 yet. There were patches to make part of the arm32 dma ops generic but we are dropping this approach as we don't want to implement another allocator. It's best to use the existing drivers/iommu/iova.c, maybe with a few bits from intel-iommu.c made generic.

Quoted 23 lines · Catalin Marinas

Quoted 14 lines · leizhen

On arm64, invoke dma_alloc_coherent will indirect call swiotlb_alloc_coherent. The latter function allocates memory by __get_free_pages or from swiotlb buffer, then use function phys_to_dma to get iova.

static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)

{
	return (dma_addr_t)paddr;
}

But dma_alloc_coherent have not use iommu_map or other functions to create mapping between iova and pa. I known that SMMUv2 support bypass mode, so there is no problem in this case. But, some device drivers need use SMMU page table to create exact mapping, to enhance security.

Quoted 4 lines

And I saw that: on X86, intel_alloc_coherent manages iova address space of each iommu_group, and create mapping between iova and pa when needed.

So, I think create mapping should be done in dma_alloc_coherent.

The swiotlb, as the name implies, is for software tlbs. IOW, nothing to do with the IOMMU.

Quoted 5 lines

We need separate dma_ops for IOMMU which are not implemented on arm64 yet. There were patches to make part of the arm32 dma ops generic but we are dropping this approach as we don't want to implement another allocator. It's best to use the existing drivers/iommu/iova.c, maybe with a few bits from intel-iommu.c made generic.

Do you have any plan work on this? If not, how about let me try first?