Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, Nov 05, 2015 at 04:11:21PM -0500, David Miller wrote: > > And for the record Sowmini fixed a lot of the lock contention: > > commit ff7d37a502022149655c18035b99a53391be0383 > Author: Sowmini Varadhan > Date: Thu Apr 9 15:33:30 2015 -0400 > > Break up

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Mon, Nov 02, 2015 at 03:44:27PM +0100, Joerg Roedel wrote: > > How do you envision this per-mapping by-pass to work? For the DMA-API > mappings you have only one device address space. For by-pass to work, > you need to map all physical memory of the machine into this space, > which leaves the

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Tue, Nov 03, 2015 at 07:13:28AM +1100, Benjamin Herrenschmidt wrote: > > Then I would argue for naming this differently. Make it an optional > hint "DMA_ATTR_HIGH_PERF" or something like that. Whether this is > achieved via using a bypass or other means in the backend not the > business of the

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Mon, Nov 02, 2015 at 09:00:34PM +1100, Benjamin Herrenschmidt wrote: > > Chosing on a per-mapping basis *in the back end* might still make some In my case, choosing mapping based on the hardware that will use this mappings makes more sense. Most hardware are not that performance sensitive as

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, Oct 29, 2015 at 10:35:25PM +, David Woodhouse wrote: > > > > Could this be mitigated using pools? I don't know if the net code > > would play along easily. > > For the receive side, it shouldn't be beyond the wit of man to > introduce an API which allocates *and* DMA-maps a skb.

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Mon, Nov 02, 2015 at 08:10:49AM +1100, Benjamin Herrenschmidt wrote: > But but but ... > > What I don't understand is how that brings you any safety. Limited safety maybe? If some device DMA mappings are via IOMMU and this fall to some address range that is far from the bypass / pass

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, Oct 29, 2015 at 09:42:12AM +0900, David Woodhouse wrote: > Aside from the lack of security, the other disadvantage of that is that > you have to pin *all* pages of a guest in case DMA happens; you don't > get to pin *only* those pages which are referenced by that guest's > IOMMU page

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Wed, Oct 28, 2015 at 03:30:01PM +0900, David Woodhouse wrote: > > > +For systems with IOMMU it is assumed all DMA translations use the IOMMU. > > Not entirely true. We have per-device dma_ops on a most architectures > already, and we were just talking about the need to add them to >