Re: WARNING in dma_map_page_attrs

2020-10-23 Thread syzbot
syzbot has found a reproducer for the following issue on: HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of git://git.kernel.org/.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=1312539050 kernel config:

Re: [PATCH v4 0/7] arm64: Default to 32-bit wide ZONE_DMA

2020-10-23 Thread Jeremy Linton
Hi, On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote: Using two distinct DMA zones turned out to be problematic. Here's an attempt go back to a saner default. I tested this on both a RPi4 and QEMU. I've tested this in ACPI mode on the rpi4 (4+8G with/without the 3G limiter) as well, with

Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-23 Thread Catalin Marinas
On Fri, Oct 23, 2020 at 05:27:49PM +0200, Nicolas Saenz Julienne wrote: > On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote: > > On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote: > > > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int > > >

Re: [PATCH 2/4] iommu/mediatek: Add iotlb_sync_range() support

2020-10-23 Thread Robin Murphy
On 2020-10-23 06:57, chao hao wrote: On Wed, 2020-10-21 at 17:55 +0100, Robin Murphy wrote: On 2020-10-19 12:30, Chao Hao wrote: MTK_IOMMU driver writes one page entry and does tlb flush at a time currently. More optimal would be to aggregate the writes and flush BUS buffer in the end.

Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-23 Thread Nicolas Saenz Julienne
Hi Catalin, On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote: > On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote: > > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int > > zone_bits) > > static void __init zone_sizes_init(unsigned long min,

Re: [PATCH v3 11/24] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek

2020-10-23 Thread Robin Murphy
On 2020-09-30 08:06, Yong Wu wrote: The standard input iova bits is 32. MediaTek quad the lvl1 pagetable (4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach 34bit. Signed-off-by: Yong Wu --- drivers/iommu/io-pgtable-arm-v7s.c | 13 ++--- drivers/iommu/mtk_iommu.c

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-10-23 Thread Tomasz Nowicki
On 10/23/20 12:33 PM, Robin Murphy wrote: On 2020-10-23 13:19, Tomasz Nowicki wrote: Hi Denis, Sorry for late response, we had to check few things. Please see comments inline. On 10/6/20 3:16 PM, Denis Odintsov wrote: Hi, Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki : The series is

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-23 Thread Jean-Philippe Brucker
On Mon, Oct 19, 2020 at 02:16:08PM -0700, Raj, Ashok wrote: > Hi Jean > > On Mon, Oct 19, 2020 at 04:08:24PM +0200, Jean-Philippe Brucker wrote: > > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > > > For devices that *don't* use a stop marker, the PCIe spec says > > > >

Re: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes

2020-10-23 Thread Jean-Philippe Brucker
On Mon, Oct 19, 2020 at 11:33:16AM -0700, Jacob Pan wrote: > Hi Jean-Philippe, > > On Mon, 19 Oct 2020 16:08:24 +0200, Jean-Philippe Brucker > wrote: > > > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote: > > > > For devices that *don't* use a stop marker, the PCIe spec says > > > >

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-10-23 Thread Denis Odintsov
Hi, > Am 23.10.2020 um 14:19 schrieb Tomasz Nowicki : > > Hi Denis, > > Sorry for late response, we had to check few things. Please see comments > inline. > > On 10/6/20 3:16 PM, Denis Odintsov wrote: >> Hi, >>> Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki : >>> >>> The series is meant to

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-10-23 Thread Robin Murphy
On 2020-10-23 13:19, Tomasz Nowicki wrote: Hi Denis, Sorry for late response, we had to check few things. Please see comments inline. On 10/6/20 3:16 PM, Denis Odintsov wrote: Hi, Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki : The series is meant to support SMMU for AP806 and a

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-10-23 Thread Tomasz Nowicki
Hi Denis, Sorry for late response, we had to check few things. Please see comments inline. On 10/6/20 3:16 PM, Denis Odintsov wrote: Hi, Am 15.07.2020 um 09:06 schrieb Tomasz Nowicki : The series is meant to support SMMU for AP806 and a workaround for accessing ARM SMMU 64bit registers is

Re: [PATCH v3 11/14] iommu/ioasid: Support mm type ioasid_set notifications

2020-10-23 Thread Jean-Philippe Brucker
On Mon, Sep 28, 2020 at 02:38:38PM -0700, Jacob Pan wrote: > As a system-wide resource, IOASID is often shared by multiple kernel > subsystems that are independent of each other. However, at the > ioasid_set level, these kernel subsystems must communicate with each > other for ownership checking,

Re: [PATCH v3 10/14] iommu/ioasid: Introduce notification APIs

2020-10-23 Thread Jean-Philippe Brucker
On Mon, Sep 28, 2020 at 02:38:37PM -0700, Jacob Pan wrote: > Relations among IOASID users largely follow a publisher-subscriber > pattern. E.g. to support guest SVA on Intel Scalable I/O Virtualization > (SIOV) enabled platforms, VFIO, IOMMU, device drivers, KVM are all users > of IOASIDs. When a

Re: [PATCH v3 09/14] iommu/ioasid: Introduce ioasid_set private ID

2020-10-23 Thread Jean-Philippe Brucker
On Mon, Sep 28, 2020 at 02:38:36PM -0700, Jacob Pan wrote: > When an IOASID set is used for guest SVA, each VM will acquire its > ioasid_set for IOASID allocations. IOASIDs within the VM must have a > host/physical IOASID backing, mapping between guest and host IOASIDs can > be non-identical.

Re: [PATCH v3 10/24] iommu/io-pgtable-arm-v7s: Add cfg as a param in some macros

2020-10-23 Thread Will Deacon
On Wed, Sep 30, 2020 at 03:06:33PM +0800, Yong Wu wrote: > Add "cfg" as a parameter for some macros. This is a preparing patch for > mediatek extend the lvl1 pgtable. No functional change. > > Signed-off-by: Yong Wu > --- > drivers/iommu/io-pgtable-arm-v7s.c | 34 +++---

Re: [PATCH v3 09/24] iommu/io-pgtable-arm-v7s: Extend PA34 for MediaTek

2020-10-23 Thread Will Deacon
On Wed, Sep 30, 2020 at 03:06:32PM +0800, Yong Wu wrote: > MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34. > > Signed-off-by: Yong Wu > --- > drivers/iommu/io-pgtable-arm-v7s.c | 9 +++-- > drivers/iommu/mtk_iommu.c | 2 +- > include/linux/io-pgtable.h | 4

Re: [PATCH v3 11/24] iommu/io-pgtable-arm-v7s: Quad lvl1 pgtable for MediaTek

2020-10-23 Thread Will Deacon
On Wed, Sep 30, 2020 at 03:06:34PM +0800, Yong Wu wrote: > The standard input iova bits is 32. MediaTek quad the lvl1 pagetable > (4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach > 34bit. > > Signed-off-by: Yong Wu > --- > drivers/iommu/io-pgtable-arm-v7s.c | 13

Re: [PATCH v3 08/24] iommu/io-pgtable-arm-v7s: Use ias to check the valid iova in unmap

2020-10-23 Thread Will Deacon
On Wed, Sep 30, 2020 at 03:06:31PM +0800, Yong Wu wrote: > Use the ias for the valid iova checking in arm_v7s_unmap. This is a > preparing patch for supporting iova 34bit for MediaTek. > BTW, change the ias/oas checking format in arm_v7s_map. > > Signed-off-by: Yong Wu > --- >

Re: [PATCH] dma-mapping: document dma_{alloc,free}_pages

2020-10-23 Thread Robin Murphy
On 2020-10-23 07:45, Christoph Hellwig wrote: Document the new dma_alloc_pages and dma_free_pages APIs, and fix up the documentation for dma_alloc_noncoherent and dma_free_noncoherent. Reported-by: Robin Murphy Signed-off-by: Christoph Hellwig --- Documentation/core-api/dma-api.rst | 49

[PATCH] iommu: Modify the description of iommu_sva_unbind_device

2020-10-23 Thread Chen Jun
From: Chen Jun iommu_sva_unbind_device has no return value. Remove the description of the return value of the function. Signed-off-by: Chen Jun --- drivers/iommu/iommu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 8c470f4..bb51d53

Re: [PATCH v4 7/7] mm: Remove examples from enum zone_type comment

2020-10-23 Thread Christoph Hellwig
Looks good, Reviewed-by: Christoph Hellwig ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance

2020-10-23 Thread Christoph Hellwig
On Thu, Oct 15, 2020 at 04:43:01PM +0100, Christoph Hellwig wrote: > > Somewhat related, but is there a way to tell the dma-api to fail instead > > of falling back to swiotlb? In many case for gpu drivers it's much better > > if we fall back to dma_alloc_coherent and manage the copying ourselves >

[PATCH] dma-mapping: document dma_{alloc,free}_pages

2020-10-23 Thread Christoph Hellwig
Document the new dma_alloc_pages and dma_free_pages APIs, and fix up the documentation for dma_alloc_noncoherent and dma_free_noncoherent. Reported-by: Robin Murphy Signed-off-by: Christoph Hellwig --- Documentation/core-api/dma-api.rst | 49 ++ 1 file changed, 43

[PATCH for-5.10] swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single

2020-10-23 Thread Christoph Hellwig
The tbl_dma_addr argument is used to check the DMA boundary for the allocations, and thus needs to be a dma_addr_t. swiotlb-xen instead passed a physical address, which could lead to incorrect results for strange offsets. Fix this by removing the parameter entirely and hard code the DMA address

Re: [PATCH 2/4] iommu/mediatek: Add iotlb_sync_range() support

2020-10-23 Thread chao hao
On Fri, 2020-10-23 at 13:57 +0800, chao hao wrote: > On Wed, 2020-10-21 at 17:55 +0100, Robin Murphy wrote: > > On 2020-10-19 12:30, Chao Hao wrote: > > > MTK_IOMMU driver writes one page entry and does tlb flush at a time > > > currently. More optimal would be to aggregate the writes and flush >

Re: [PATCH 2/4] iommu/mediatek: Add iotlb_sync_range() support

2020-10-23 Thread chao hao
On Wed, 2020-10-21 at 17:55 +0100, Robin Murphy wrote: > On 2020-10-19 12:30, Chao Hao wrote: > > MTK_IOMMU driver writes one page entry and does tlb flush at a time > > currently. More optimal would be to aggregate the writes and flush > > BUS buffer in the end. > > That's exactly what