On Tue, Oct 03, 2017 at 05:43:47PM -0700, Nadav Amit wrote:
> Jerome Glisse wrote:
>
> > On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote:
> >
> >> I'd like some more explanation about the inner working of "that new
> >> user" as per comment above.
> >>
> >> It would be enough t
On 04.10.2017 04:02, Dmitry Osipenko wrote:
> Due to a bug in IOVA allocator, page mapping could accidentally overwritten.
> We can catch this case by checking 'VALID' bit of GART's page entry prior to
> mapping of a page. Since that check introduces a noticeable performance
> impact, it should be
Due to a bug in IOVA allocator, page mapping could accidentally overwritten.
We can catch this case by checking 'VALID' bit of GART's page entry prior to
mapping of a page. Since that check introduces a noticeable performance
impact, it should be enabled explicitly by a new CONFIG_TEGRA_IOMMU_GART_
This is a continuation of the "iommu/tegra: gart: Couple corrections"
patchset that was send out quite some time ago and reviewed by Thierry Reding
recently.
Change log:
v2:
- Dropped "Don't unnecessarily allocate registers context" patch
as it is not entirely correct.
Due to a bug in IOVA allocator, page mapping could accidentally overwritten.
We can catch this case by checking 'VALID' bit of GART's page entry prior to
mapping of a page. Since that check introduces a noticeable performance
impact, it should be enabled explicitly by a new CONFIG_TEGRA_IOMMU_GART_
Validation of page frame number doesn't require protection with a spinlock,
let's move it out of spinlock for consistency.
Signed-off-by: Dmitry Osipenko
Acked-by: Thierry Reding
---
drivers/iommu/tegra-gart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu
Jerome Glisse wrote:
> On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote:
>
>> I'd like some more explanation about the inner working of "that new
>> user" as per comment above.
>>
>> It would be enough to drop mmu_notifier_invalidate_range from above
>> without adding it to the
On Wed, Oct 04, 2017 at 01:42:15AM +0200, Andrea Arcangeli wrote:
> Hello Jerome,
>
> On Fri, Sep 01, 2017 at 01:30:11PM -0400, Jerome Glisse wrote:
> > +Case A is obvious you do not want to take the risk for the device to write
> > to
> > +a page that might now be use by some completely differen
Hello Jerome,
On Fri, Sep 01, 2017 at 01:30:11PM -0400, Jerome Glisse wrote:
> +Case A is obvious you do not want to take the risk for the device to write to
> +a page that might now be use by some completely different task.
used
> +is true ven if the thread doing the page table update is preemp
Hi Robin
I now see your patch and it does seem to be fix the problem.
On Thu, Sep 28, 2017 at 08:43:46AM -0700, Ashok Raj wrote:
> Hi Robin
>
>
> On Thu, Sep 28, 2017 at 05:59:11PM +0100, Robin Murphy wrote:
> > I hope our email server hasn't got blacklisted again... Said patch is
> > the top o
| From: Harsh Jain
| Sent: Tuesday, October 3, 2017 5:22 AM
|
| Hi Robin/Ashok,
|
| Find attached trace of DMA write error. I had a look on trace but didn't
| find anything suspicious.
|
| Let me know if you need more trace.
As a reminder, Harsh and Atul will be waking up in a few hours, so if th
On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote:
>
> Now, there are indeed plenty of drivers and subsystems which do work on
> lists of explicitly single pages - anything doing some variant of
> "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I
> don't think DMA API imp
smime.p7m
Description: S/MIME encrypted message
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, Sep 22, 2017 at 06:45:26AM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Update the IPMMU DT binding documentation to include the r8a77995 compat
> string for the IPMMU devices included in the R-Car D3 SoC.
>
> Signed-off-by: Magnus Damm
> ---
>
> Documentation/devicetree/bindings
On Fri, Sep 22, 2017 at 06:45:16AM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Update the IPMMU DT binding documentation to include the r8a77970 compat
> string for the IPMMU devices included in the R-Car V3M SoC.
>
> Signed-off-by: Magnus Damm
> ---
>
> Documentation/devicetree/binding
On Tue, 3 Oct 2017, David Laight wrote:
> From: Christoph Hellwig
> > Sent: 03 October 2017 11:43
> > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
> > make any sense to do any work in dma_cache_sync given that it must be a
> > no-op when dma_alloc_attrs returns coheren
On 03/10/17 13:55, David Woodhouse wrote:
> On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
>> The intel-iommu DMA ops fail to correctly handle scatterlists where
>> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
>> appropriately based on the page-aligned portion of t
From: Christoph Hellwig
> Sent: 03 October 2017 11:43
> x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
> make any sense to do any work in dma_cache_sync given that it must be a
> no-op when dma_alloc_attrs returns coherent memory.
I believe it is just about possible to r
Le 03/10/2017 à 12:43, Christoph Hellwig a écrit :
powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
What about arch/powerpc/mm/dma-noncoheren
Hi Jean,
On 04/08/2017 20:19, Jean-Philippe Brucker wrote:
> This is the continuation of my proposal for virtio-iommu, the para-
> virtualized IOMMU. Here is a summary of the changes since last time [1]:
>
> * The virtio-iommu document now resembles an actual specification. It is
> split into a
On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
> The intel-iommu DMA ops fail to correctly handle scatterlists where
> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
> appropriately based on the page-aligned portion of the offset, but the
> mapping is set up relative
On 03/10/17 11:43, Christoph Hellwig wrote:
> The dma_cache_sync routines is used to flush caches for memory returned
> by dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag (or previously
> from dma_alloc_noncoherent), but the requirements for it seems to be
> frequently misunderstood. dma_cac
On Tue, Oct 03, 2017 at 01:24:57PM +0200, Christophe LEROY wrote:
>> powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
>> doesn't make any sense to do any work in dma_cache_sync given that it
>> must be a no-op when dma_alloc_attrs returns coherent memory.
> What about arch/powe
On 03/10/17 12:24, Christophe LEROY wrote:
>
>
> Le 03/10/2017 à 12:43, Christoph Hellwig a écrit :
>> powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
>> doesn't make any sense to do any work in dma_cache_sync given that it
>> must be a no-op when dma_alloc_attrs returns coh
sh does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
On the other hand sh uses dma_cache_sync internally in the dma_ops
implementation and for the maple b
After we removed all the dead wood it turns out only two architectures
actually implement dma_cache_sync as a real op: mips and parisc. Add
a cache_sync method to struct dma_map_ops and implement it for the
mips defualt DMA ops, and the parisc pa11 ops.
Note that arm, arc and openrisc support DMA
xtensa does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/include/asm/dma-mapping.h | 6 --
arch/xt
frv does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
make any sense to do any work in dma_cache_sync given that it must be a
no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/frv/include/asm/dma-mapping.h | 1 -
1 file changed, 1 d
unicore32 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/unicore32/include/asm/cacheflush.h | 9 -
mn10300 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it must
be a no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/mn10300/include/asm/dma-mapping.h | 4
1 file c
powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 2 --
1 file cha
ia64 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
make any sense to do any work in dma_cache_sync given that it must be a
no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/dma-mapping.h | 5 -
1 file change
microblaze does not implement DMA_ATTR_NON_CONSISTENT allocations, so it
doesn't make any sense to do any work in dma_cache_sync given that it
must be a no-op when dma_alloc_attrs returns coherent memory.
This also allows moving __dma_sync out of the microblaze asm/dma-mapping.h
and thus greatly r
x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't
make any sense to do any work in dma_cache_sync given that it must be a
no-op when dma_alloc_attrs returns coherent memory.
Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
---
arch/x86/include/asm/dma-mappin
The dma_cache_sync routines is used to flush caches for memory returned
by dma_alloc_attrs with the DMA_ATTR_NON_CONSISTENT flag (or previously
from dma_alloc_noncoherent), but the requirements for it seems to be
frequently misunderstood. dma_cache_sync is documented to be a no-op for
allocations
Only mips defines this helper, so remove all the other arch definitions.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/floppy.h| 2 --
arch/powerpc/include/asm/floppy.h | 2 --
arch/sparc/include/asm/floppy_32.h | 1 -
arch/sparc/include/asm/floppy_64.h | 1 -
drivers/block/fl
On Mon, Oct 02, 2017 at 06:30:41PM +0800, Miles Chen wrote:
> ARCHs like metag and xtensa define their mappings (non-vmalloc and
> non-linear) for dma allocation.
metag basically is a reimplementation of the vmalloc map mechanism
that should be easy to consolidate into the common one :( xtensa
ha
37 matches
Mail list logo
