Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

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

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

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

Re: [PATCH 3/3] iommu/ipmmu-vmsa: Document R-Car D3 IPMMU DT bindings

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

unsubscribe

smime.p7m Description: S/MIME encrypted message ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/3] iommu/ipmmu-vmsa: Document R-Car V3M IPMMU DT 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

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

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. > >> > >>

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

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

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

| 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

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

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

[PATCH 03/11] frv: make dma_cache_sync a no-op

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

[PATCH 08/11] unicore32: make dma_cache_sync a no-op

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

[PATCH 09/11] xtensa: make dma_cache_sync a no-op

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

[PATCH 10/11] sh: make dma_cache_sync a no-op

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

[PATCH 06/11] mn10300: make dma_cache_sync a no-op

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

[PATCH 05/11] microblaze: make dma_cache_sync a no-op

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

[PATCH 04/11] ia64: make dma_cache_sync a no-op

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 -

refactor dma_cache_sync V2

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

[PATCH 01/11] floppy: consolidate the dummy fd_cacheflush definition

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 -

[PATCH 02/11] x86: make dma_cache_sync a no-op

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

[PATCH 07/11] powerpc: make dma_cache_sync a no-op

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

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

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

Re: refactor dma_cache_sync V2

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.

Re: [PATCH v3] dma-debug: fix incorrect pfn calculation

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

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

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

Re: [virtio-dev] [RFC] virtio-iommu version 0.4

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

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

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

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

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

[PATCH v2 2/2] iommu/tegra: gart: Move PFN validation out of spinlock

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

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

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

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

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

Re: [PATCH] mm/mmu_notifier: avoid double notification when it is useless

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 >>

[PATCH v2 1/2] iommu/tegra: gart: Optionally check for overwriting of page mappings

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

[PATCH v2 0/2] TEGRA GART cleanup and new debug option

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.

[PATCH v2 1/2] iommu/tegra: gart: Add optional debug checking for overwriting of page mappings

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

Re: [PATCH v2 1/2] iommu/tegra: gart: Add optional debug checking for overwriting of page mappings

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