search for: dma_alloc_pages

Switch from coherent DMA pools to those backed by dma_alloc_pages. This helps device with non-coherent DMA to avoid host accesses to uncached memory for every submission of a larger than single entry I/O. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/nvme/host/pci.c | 80 ++++++++++++++++++++--------------------- 1 file changed, 40 inserti...

...2020 at 03:07:04PM +0100, Robin Murphy wrote: >> FWIW, I asked back in time what the plan is for non-coherent >> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and >> dma_sync_*() was supposed to be the right thing to go with. [2] The >> same thread also explains why dma_alloc_pages() isn't suitable for the >> users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of NON_CONSISTENT > and *replacing* it with something streaming-API-based - i.e. this series - > not encouraging mixing the existi...

...cally sized pool of shared > pages that can live anywhere. I think that can be done relatively easily. I've actually been thinking of multiple pool support for a wh?le to replace the bounce buffering in the block layer for ISA devices (24-bit addressing). I've also been looking into a dma_alloc_pages interface to help people just allocate pages that are always dma addressable, but don't need a coherent allocation. My last version I shared is here: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_pages But it turns out this still doesn't work with SEV as we...

...I is the equivalent of alloc_pages, except that the returned memory is guaranteed to be DMA addressable by the passed in device. The implementation will also be used to provide a more sensible replacement for DMA_ATTR_NON_CONSISTENT flag. Additionally dma_alloc_noncoherent is switched over to use dma_alloc_pages as its backend. Signed-off-by: Christoph Hellwig <hch at lst.de> --- Documentation/core-api/dma-attributes.rst | 8 --- arch/alpha/kernel/pci_iommu.c | 2 + arch/arm/mm/dma-mapping-nommu.c | 2 + arch/arm/mm/dma-mapping.c | 4 ++ arch/ia64/hp/common...

...sable. If you don't understand how cache line coherency works between a processor and an I/O device, you should not be using this part of the -API at all. +API. :: void * - dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle, - gfp_t flag, unsigned long attrs) + dma_alloc_pages(struct device *dev, size_t size, dma_addr_t *dma_handle, + enum dma_data_direction dir, gfp_t gfp) + +This routine allocates a region of <size> bytes of consistent memory. It +returns a pointer to the allocated region (in the processor's virtual address +space) or NULL if the allocatio...

...0100, Robin Murphy wrote: > >> FWIW, I asked back in time what the plan is for non-coherent > >> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > >> dma_sync_*() was supposed to be the right thing to go with. [2] The > >> same thread also explains why dma_alloc_pages() isn't suitable for the > >> users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > > > AFAICS even back then Christoph was implying getting rid of NON_CONSISTENT > > and *replacing* it with something streaming-API-based - i.e. this series - > > not encour...

...ned to get away with it for so long. > > > FWIW, I asked back in time what the plan is for non-coherent > > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > > dma_sync_*() was supposed to be the right thing to go with. [2] The > > same thread also explains why dma_alloc_pages() isn't suitable for the > > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of > NON_CONSISTENT and *replacing* it with something streaming-API-based - That's not how I read his reply from the thread I poi...

...#39;t acquired and the synchronization isn't happening, so you have a point. FWIW, I asked back in time what the plan is for non-coherent allocations and it seemed like DMA_ATTR_NON_CONSISTENT and dma_sync_*() was supposed to be the right thing to go with. [2] The same thread also explains why dma_alloc_pages() isn't suitable for the users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. I think we could make a deal here. We could revert back the parts using DMA_ATTR_NON_CONSISTENT, keeping the UAPI intact, but just rendering it no-op, since it's just a hint after all. Then, you would propose...

On Mon, Sep 14, 2020 at 04:44:16PM +0200, Christoph Hellwig wrote: > I'm still a little unsure about the API naming, as alloc_pages sort of > implies a struct page return value, but we return a kernel virtual > address. Erm ... dma_alloc_pages() returns a struct page, so is this sentence stale? >From patch 14: +struct page *dma_alloc_pages(struct device *dev, size_t size, + dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp); > The other alternative would be to name the API > dma_alloc_noncoherent, b...

On 2020-09-15 16:51, Christoph Hellwig wrote: [...] > +These APIs allow to allocate pages in the kernel direct mapping that are > +guaranteed to be DMA addressable. This means that unlike dma_alloc_coherent, > +virt_to_page can be called on the resulting address, and the resulting Nit: if we explicitly describe this as if it's a guarantee that can be relied upon... > +struct

...of code that have happened to get away with it for so long. > FWIW, I asked back in time what the plan is for non-coherent > allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > dma_sync_*() was supposed to be the right thing to go with. [2] The > same thread also explains why dma_alloc_pages() isn't suitable for the > users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. AFAICS even back then Christoph was implying getting rid of NON_CONSISTENT and *replacing* it with something streaming-API-based - i.e. this series - not encouraging mixing the existing APIs. It doesn't...

...gt; in ... I just have a vague memory that my 715 actually caught fire a > decade ago and had to be disposed of. I still have a zoo of machines running for such testing, including a 715/64 and two 730. I'm going to test this git tree on the 715/64: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Helge

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. As a follow up I plan to move the...

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a little unsure abo...

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a little unsure abo...

Thanks Michael! Actually I also hoped to start a discussion on virtio with encrypted memory. I assume the AMD folks have the most experience with this, and I very much like to understand how do they master the challenges we are all facing. My understanding of IO in the context of AMD SEV is that the user is responsible for choosing the swiotlb command line parameter of the guest kernel so, that

Thanks Michael! Actually I also hoped to start a discussion on virtio with encrypted memory. I assume the AMD folks have the most experience with this, and I very much like to understand how do they master the challenges we are all facing. My understanding of IO in the context of AMD SEV is that the user is responsible for choosing the swiotlb command line parameter of the guest kernel so, that

Hi Christoph, On 19.08.2020 08:55, Christoph Hellwig wrote: > this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs > with a separate new dma_alloc_pages API, which is available on all > platforms. In addition to cleaning up the convoluted code path, this > ensures that other drivers that have asked for better support for > non-coherent DMA to pages with incurring bounce buffering over can finally > be properly supported. > > I...

...ue memory that my 715 actually caught fire a >> decade ago and had to be disposed of. > > I still have a zoo of machines running for such testing, including a > 715/64 and two 730. > I'm going to test this git tree on the 715/64: > git://git.infradead.org/users/hch/misc.git dma_alloc_pages This tree boots nicely (up to a command prompt with i82596 nic working): 53c700: Version 2.8 By James.Bottomley at HansenPartnership.com scsi0: 53c710 rev 2 scsi host0: LASI SCSI 53c700 scsi 0:0:6:0: Direct-Access QUANTUM FIREBALL_TM3200S 300X PQ: 0 ANSI: 2 scsi target0:0:6: Beginning Domain...

On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: > I think this looks mostly OK, except for one misnamed parameter below. > Unfortunately, the last non-coherent parisc was the 700 series and I no > longer own a box, so I can't test that part of it (I can fire up the > C360 to test it on a coherent arch). I have a 715/50 that probably hasn't been powered on in