[GIT PULL] dma mapping fix for 4.17

The following changes since commit b284d4d5a6785f8cd07eda2646a95782373cd01e: Merge tag 'ceph-for-4.17-rc1' of git://github.com/ceph/ceph-client (2018-04-10 12:25:30 -0700) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.17-2 for

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Vivek, On 2018/4/11 13:15, Vivek Gautam wrote: > Hi Yisheng, > > > On 4/11/2018 6:52 AM, Yisheng Xie wrote: >> Hi Tomasz, >> >> On 2018/4/10 21:14, Tomasz Figa wrote: >>> Hi Yisheng, >>> >>> Sorry, I think we missed your question here. >>> >>> On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie

Re: [VERY RFC 0/2] iommu: optionally skip attaching to a DMA domain

On Wed, Apr 11, 2018 at 2:55 PM, Jordan Crouse wrote: > I've been struggling with a problem for a while and I haven't been able to > come > up with a clean solution. Rob convinced me to stop complaining and do > _something_ and hopefully this can spur a good discussion. >

Re: [PATCH RFC 1/1] iommu/of: Deconfigure iommu on driver detach

Hi Robin, On 4/3/2018 4:27 PM, Robin Murphy wrote: On 28/03/18 11:25, Vivek Gautam wrote: As part of dma_deconfigure, lets deconfigure the iommu too on driver detach, so that we clear the iommu domain and related group. Signed-off-by: Vivek Gautam --- As a part

[PATCH 2/2] iommu/arm-smmu: Add list of devices to opt out of DMA domains

Add a list of compatible strings for devices that wish to opt out of attaching to a DMA domain. This is for devices that prefer to manage their own IOMMU space for any number of reasons. Returning ENOTSUPP for attach device will filter down and force arch_setup_dma_ops() to not set up the iommu

[PATCH 1/2] iommu: Gracefully allow drivers to not attach to a default domain

Provide individual device drivers the chance to gracefully refuse to attach a device to the default domain. If the attach_device op returns -ENOTSUPP don't print a error message and don't set group->domain but still return success from iommu_group_add_dev(). This allows all the usual APIs to work

[VERY RFC 0/2] iommu: optionally skip attaching to a DMA domain

I've been struggling with a problem for a while and I haven't been able to come up with a clean solution. Rob convinced me to stop complaining and do _something_ and hopefully this can spur a good discussion. The scenario is basically this: The MSM GPU wants to manage its own IOMMU virtual

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

On 23/03/18 08:27, Tian, Kevin wrote: >>> The host kernel needs to have *some* MSI region in place before the >>> guest can start configuring interrupts, otherwise it won't know what >>> address to give to the underlying hardware. However, as soon as the host >>> kernel has picked a region, host

Re: [PATCH 2/4] iommu/virtio: Add probe request

On 23/03/18 15:00, Robin Murphy wrote: [...] >> +/* >> + * Treat unknown subtype as RESERVED, but urge users to update their >> + * driver. >> + */ >> +if (mem->subtype != VIRTIO_IOMMU_RESV_MEM_T_RESERVED && >> +mem->subtype != VIRTIO_IOMMU_RESV_MEM_T_MSI) >> +

Re: [PATCH 1/4] iommu: Add virtio-iommu driver

On 23/03/18 14:48, Robin Murphy wrote: [..] >> + * Virtio driver for the paravirtualized IOMMU >> + * >> + * Copyright (C) 2018 ARM Limited >> + * Author: Jean-Philippe Brucker >> + * >> + * SPDX-License-Identifier: GPL-2.0 > > This wants to be a // comment at the

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

Hi Sammer, On 11/04/18 16:58, Goel, Sameer wrote: > > > On 3/28/2018 9:00 AM, Marc Zyngier wrote: >> On 2018-03-28 15:39, Timur Tabi wrote: >>> From: Sameer Goel >>> >>> Set SMMU_GBPA to abort all incoming translations during the SMMU reset >>> when SMMUEN==0. >>> >>>

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 3/28/2018 9:00 AM, Marc Zyngier wrote: > On 2018-03-28 15:39, Timur Tabi wrote: >> From: Sameer Goel >> >> Set SMMU_GBPA to abort all incoming translations during the SMMU reset >> when SMMUEN==0. >> >> This prevents a race condition where a stray DMA from the crashed

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 4/5/2018 5:26 AM, Will Deacon wrote: > On Wed, Mar 28, 2018 at 09:39:40AM -0500, Timur Tabi wrote: >> From: Sameer Goel >> >> Set SMMU_GBPA to abort all incoming translations during the SMMU reset >> when SMMUEN==0. >> >> This prevents a race condition where a stray DMA

[git pull] IOMMU Updates for Linux v4.17

Hi Linus, The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274: Linux 4.16-rc7 (2018-03-25 12:44:30 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v4.17 for you to fetch changes up to

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 11/04/18 15:33, Sinan Kaya wrote: On 4/11/2018 8:03 AM, Robin Murphy wrote: On 10/04/18 21:59, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 4/11/2018 8:03 AM, Robin Murphy wrote: > On 10/04/18 21:59, Sinan Kaya wrote: >> Code is expecing to observe the same number of buffers returned from >> dma_map_sg() function compared to sg_alloc_table_from_pages(). This >> doesn't hold true universally especially for systems with IOMMU. > >

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 10/04/18 21:59, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems with IOMMU. So why not fix said code? It's clearly not a real

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

On Tue, 10 Apr 2018 20:10:20 +0200, Christoph Hellwig wrote: > > On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote: > > In the first one, the machine appears to have enough RAM that most of it is > > beyond the device's 36-bit DMA mask, thus it's fairly likely for the > > initial