Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-14 Thread Christoph Hellwig
> +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np) > +{ > + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX; > + struct of_range_parser parser; > + phys_addr_t subtree_max_addr; > + struct device_node *child; > + phys_addr_t cpu_end = 0; > + struct of_range

Re: [PATCH v3 8/8] mm: Update DMA zones description

2020-10-14 Thread Christoph Hellwig
On Wed, Oct 14, 2020 at 09:12:10PM +0200, Nicolas Saenz Julienne wrote: > The default behavior for arm64 changed, so reflect that. > > Signed-off-by: Nicolas Saenz Julienne > Acked-by: Catalin Marinas > --- > include/linux/mmzone.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) >

Re: [PATCH v3 6/8] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-14 Thread Christoph Hellwig
On Wed, Oct 14, 2020 at 09:12:08PM +0200, Nicolas Saenz Julienne wrote: > + zone_dma_bits = min(zone_dma_bits, > + (unsigned > int)ilog2(of_dma_get_max_cpu_address(NULL))); Plase avoid pointlessly long lines. Especially if it is completely trivial by using either

Re: [PATCH v3 5/8] dma-direct: Turn zone_dma_bits default value into a define

2020-10-14 Thread Christoph Hellwig
On Wed, Oct 14, 2020 at 09:12:07PM +0200, Nicolas Saenz Julienne wrote: > Set zone_dma_bits default value through a define so as for architectures > to be able to override it with their default value. Architectures can do that already by assigning a value to zone_dma_bits at runtime. I really do

Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support

2020-10-14 Thread Nicolin Chen
On Wed, Oct 14, 2020 at 06:42:36PM +0100, Robin Murphy wrote: > On 2020-10-09 17:19, Nicolin Chen wrote: > > This patch simply adds support for PCI devices. > > > > Reviewed-by: Dmitry Osipenko > > Tested-by: Dmitry Osipenko > > Signed-off-by: Nicolin Chen > > --- > > > > Changelog > > v6->v7

[PATCH] iommu/amd: Increase interrupt remapping table limit to 512 entries

2020-10-14 Thread Suravee Suthikulpanit
Certain device drivers allocate IO queues on a per-cpu basis. On AMD EPYC platform, which can support up-to 256 cpu threads, this can exceed the current MAX_IRQ_PER_TABLE limit of 256, and result in the error message: AMD-Vi: Failed to allocate IRTE This has been observed with certain NVME

Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

2020-10-14 Thread Alex Williamson
On Wed, 14 Oct 2020 03:08:31 + "Tian, Kevin" wrote: > > From: Jason Wang > > Sent: Tuesday, October 13, 2020 2:22 PM > > > > > > On 2020/10/12 下午4:38, Tian, Kevin wrote: > > >> From: Jason Wang > > >> Sent: Monday, September 14, 2020 12:20 PM > > >> > > > [...] > > > > If it's

Re: [PATCH v3 4/8] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne wrote: > > Introduce a test for of_dma_get_max_cup_address(), it uses the same DT > data as the rest of dma-ranges unit tests. > > Signed-off-by: Nicolas Saenz Julienne > --- > drivers/of/unittest.c | 20 > 1 file

Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne wrote: > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > physical address addressable by all DMA masters in the system. It's > specially useful for setting memory zones sizes at early boot time. > > Signed-off-by:

Re: [git pull] IOMMU Updates for Linux v5.10

2020-10-14 Thread pr-tracker-bot
The pull request you sent on Tue, 13 Oct 2020 18:03:58 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > tags/iommu-updates-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/531d29b0b674036347a04c08c0898ff1aa522180 Thank you! --

Re: [git pull] IOMMU Updates for Linux v5.10

2020-10-14 Thread Linus Torvalds
On Tue, Oct 13, 2020 at 9:04 AM Joerg Roedel wrote: > > there is a minor conflict this time in include/linux/iommu.h which > should be easy to resolve. I would attach my resolution, but somehow git > [show|log] didn't show it to me. So when a resolution takes one side over the other (as opposed

[PATCH v3 4/8] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-14 Thread Nicolas Saenz Julienne
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT data as the rest of dma-ranges unit tests. Signed-off-by: Nicolas Saenz Julienne --- drivers/of/unittest.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/of/unittest.c

[PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-14 Thread Nicolas Saenz Julienne
From: Ard Biesheuvel We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge

[PATCH v3 2/8] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

2020-10-14 Thread Nicolas Saenz Julienne
zone_dma_bits's initialization happens earlier that it's actually needed, in arm64_memblock_init(). So move it into the more suitable zone_sizes_init(). Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH v3 6/8] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-14 Thread Nicolas Saenz Julienne
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms incorporating masters that can address less than 32 bits of DMA, in particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has peripherals that can only address up to 1 GB (and its PCIe host bridge can only access the

[PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-14 Thread Nicolas Saenz Julienne
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU physical address addressable by all DMA masters in the system. It's specially useful for setting memory zones sizes at early boot time. Signed-off-by: Nicolas Saenz Julienne --- Changes since v2: - Use PHYS_ADDR_MAX -

[PATCH v3 0/8] arm64: Default to 32-bit wide ZONE_DMA

2020-10-14 Thread Nicolas Saenz Julienne
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. --- Changes since v2: - Introduce Ard's patch - Improve OF dma-ranges parsing function - Add unit test for OF function - Address small changes -

[PATCH v3 5/8] dma-direct: Turn zone_dma_bits default value into a define

2020-10-14 Thread Nicolas Saenz Julienne
Set zone_dma_bits default value through a define so as for architectures to be able to override it with their default value. Signed-off-by: Nicolas Saenz Julienne --- include/linux/dma-direct.h | 3 +++ kernel/dma/direct.c| 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff

[PATCH v3 1/8] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-10-14 Thread Nicolas Saenz Julienne
crashkernel might reserve memory located in ZONE_DMA. We plan to delay ZONE_DMA's initialization after unflattening the devicetree and ACPI's boot table initialization, so move it later in the boot process. Specifically into mem_init(), this is the last place crashkernel will be able to reserve

[PATCH v3 8/8] mm: Update DMA zones description

2020-10-14 Thread Nicolas Saenz Julienne
The default behavior for arm64 changed, so reflect that. Signed-off-by: Nicolas Saenz Julienne Acked-by: Catalin Marinas --- include/linux/mmzone.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index

Re: [PATCH v7 3/3] iommu/tegra-smmu: Add PCI support

2020-10-14 Thread Robin Murphy
On 2020-10-09 17:19, Nicolin Chen wrote: This patch simply adds support for PCI devices. Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Signed-off-by: Nicolin Chen --- Changelog v6->v7 * Renamed goto labels, suggested by Thierry. v5->v6 * Added Dmitry's Reviewed-by and

RE: [PATCH 8/8] WIP: add a dma_alloc_contiguous API

2020-10-14 Thread David Laight
> On Wed, Sep 30, 2020 at 6:09 PM Christoph Hellwig wrote: > > > > Add a new API that returns a virtually non-contigous array of pages > > and dma address. This API is only implemented for dma-iommu and will > > not be implemented for non-iommu DMA API instances that have to allocate > >

Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API

2020-10-14 Thread Tomasz Figa
+CC Ricardo who will be looking into using this in the USB stack (UVC camera driver). On Wed, Sep 30, 2020 at 6:09 PM Christoph Hellwig wrote: > > Add a new API that returns a virtually non-contigous array of pages > and dma address. This API is only implemented for dma-iommu and will > not be

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-14 Thread Joerg Roedel
On Wed, Oct 14, 2020 at 03:25:08PM +0800, Lu Baolu wrote: > I suppose Joerg will pick this up. I guess you don't need to resend it > unless Joerg asks you to do. Yes, will pick this up soon, no need to re-send. Thanks, Joerg ___ iommu mailing

Re: [PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-14 Thread Rob Herring
On Wed, Oct 14, 2020 at 6:52 AM Nicolas Saenz Julienne wrote: > > Hi Rob, > > On Mon, 2020-10-12 at 10:25 -0500, Rob Herring wrote: > > On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne > > wrote: > > > The function provides the CPU physical address addressable by the most > > >

Re: [PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-14 Thread Nicolas Saenz Julienne
Hi Rob, On Mon, 2020-10-12 at 10:25 -0500, Rob Herring wrote: > On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne > wrote: > > The function provides the CPU physical address addressable by the most > > constrained bus in the system. It might be useful in order to > > dynamically set up

Re: [PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-14 Thread Nicolas Saenz Julienne
On Sun, 2020-10-11 at 09:47 +0200, Ard Biesheuvel wrote: > Hi Nicolas, > > $SUBJECT is out of sync with the patch below. Also, for legibility, it > helps if the commit log is intelligible by itself, rather than relying > on $SUBJECT being the first line of the first paragraph. Noted, I'll update

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-14 Thread Lu Baolu
Hi Bartosz, On 10/14/20 3:18 PM, Bartosz Golaszewski wrote: On Wed, Oct 14, 2020 at 2:49 AM Lu Baolu wrote: On 10/13/20 3:30 PM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Since commit c40c1018 ("iommu/vt-d: Gracefully handle DMAR units with no supported address widths")

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-14 Thread Bartosz Golaszewski
On Wed, Oct 14, 2020 at 2:49 AM Lu Baolu wrote: > > On 10/13/20 3:30 PM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Since commit c40c1018 ("iommu/vt-d: Gracefully handle DMAR units > > with no supported address widths") dmar.c needs struct iommu_device to > > be