BMC/Intel-BMC/linux.git/lib/dma-direct.c, branch dev-4.17

dma-direct: try reallocation with GFP_DMA32 if possible

2018-08-03T05:47:55+00:00

[ Upstream commit de7eab301de78869322104ea13e124c936ad3e1f ] As the recent swiotlb bug revealed, we seem to have given up the direct DMA allocation too early and felt back to swiotlb allocation. The reason is that swiotlb allocator expected that dma_direct_alloc() would try harder to get pages even below 64bit DMA mask with GFP_DMA32, but the function doesn't do that but only deals with GFP_DMA case. This patch adds a similar fallback reallocation with GFP_DMA32 as we've done with GFP_DMA. The condition is that the coherent mask is smaller than 64bit (i.e. some address limitation), and neither GFP_DMA nor GFP_DMA32 is set beforehand. Signed-off-by: Takashi Iwai Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

dma-direct: don't retry allocation for no-op GFP_DMA

2018-04-23T12:43:27+00:00

When an allocation with lower dma_coherent mask fails, dma_direct_alloc() retries the allocation with GFP_DMA. But, this is useless for architectures that hav no ZONE_DMA. Fix it by adding the check of CONFIG_ZONE_DMA before retrying the allocation. Fixes: 95f183916d4b ("dma-direct: retry allocations using GFP_DMA for small masks") Signed-off-by: Takashi Iwai Signed-off-by: Christoph Hellwig

dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrs

2018-03-28T15:34:23+00:00

Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to dma_direct_alloc for now. While most common architectures always zero dma cohereny allocations (and x86 did so since day one) this is not documented and at least arc and s390 do not zero without the explicit __GFP_ZERO argument. Fixes: 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") Reported-by: Evgeniy Didin Reported-by: Sebastian Ott Signed-off-by: Christoph Hellwig Signed-off-by: Thomas Gleixner Tested-by: Evgeniy Didin Cc: iommu@lists.linux-foundation.org Link: https://lkml.kernel.org/r/20180328133535.17302-2-hch@lst.de

dma/direct: Handle force decryption for DMA coherent buffers in common code

2018-03-20T09:01:59+00:00

With that in place the generic DMA-direct routines can be used to allocate non-encrypted bounce buffers, and the x86 SEV case can use the generic swiotlb ops including nice features such as using CMA allocations. Note that I'm not too happy about using sev_active() in DMA-direct, but I couldn't come up with a good enough name for a wrapper to make it worth adding. Tested-by: Tom Lendacky Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner Cc: David Woodhouse Cc: Joerg Roedel Cc: Jon Mason Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: Muli Ben-Yehuda Cc: Peter Zijlstra Cc: iommu@lists.linux-foundation.org Link: http://lkml.kernel.org/r/20180319103826.12853-14-hch@lst.de Signed-off-by: Ingo Molnar

dma-direct: comment the dma_direct_free calling convention

2018-02-12T15:59:07+00:00

Signed-off-by: Christoph Hellwig

dma-direct: mark as is_phys

2018-02-12T15:59:06+00:00

Various PCI_DMA_BUS_IS_PHYS implementations rely on this flag to make proper decisions for block and networking addressability. Signed-off-by: Christoph Hellwig

dma-direct: reject too small dma masks

2018-01-15T08:35:15+00:00

Signed-off-by: Christoph Hellwig Reviewed-by: Robin Murphy

dma-direct: make dma_direct_{alloc,free} available to other implementations

2018-01-15T08:35:14+00:00

So that they don't need to indirect through the operation vector. Signed-off-by: Christoph Hellwig Reviewed-by: Vladimir Murzin

dma-direct: retry allocations using GFP_DMA for small masks

2018-01-15T08:35:13+00:00

If an attempt to allocate memory succeeded, but isn't inside the supported DMA mask, retry the allocation with GFP_DMA set as a last resort. Based on the x86 code, but an off by one error in what is now dma_coherent_ok has been fixed vs the x86 code. Signed-off-by: Christoph Hellwig

dma-direct: add support for allocation from ZONE_DMA and ZONE_DMA32

2018-01-15T08:35:12+00:00

This allows to dip into zones for lower memory if they are available. If one of the zones is not available the corresponding GFP_* flag will evaluate to 0 so they won't change anything. We provide an arch tunable for those architectures that do not use GFP_DMA for the lowest 24-bits, given that there are a few. Roughly based on the x86 code. Signed-off-by: Christoph Hellwig