Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

2019-06-03 Thread Michael S. Tsirkin
On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: > > > Michael S. Tsirkin writes: > > > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> I rephrased it in terms of address translation. What do you think of > >> this version? The flag name is

Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

2019-06-03 Thread Thiago Jung Bauermann
Michael S. Tsirkin writes: > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> I rephrased it in terms of address translation. What do you think of >> this version? The flag name is slightly different too: >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature

[PATCH] iommu/dma: Apply dma_{alloc,free}_contiguous functions

2019-06-03 Thread Nicolin Chen
This patch replaces dma_{alloc,release}_from_contiguous() with dma_{alloc,free}_contiguous() to simplify those function calls. Signed-off-by: Nicolin Chen --- drivers/iommu/dma-iommu.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/dma-iommu.c

Re: [PATCH v8 24/29] vfio: VFIO_IOMMU_BIND/UNBIND_MSI

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:09:59 +0200 Eric Auger wrote: > This patch adds the VFIO_IOMMU_BIND/UNBIND_MSI ioctl which aim > to pass/withdraw the guest MSI binding to/from the host. > > Signed-off-by: Eric Auger > > --- > v6 -> v7: > - removed the dev arg > > v3 -> v4: > - add UNBIND > - unwind

Re: [PATCH v8 22/29] vfio: VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:09:57 +0200 Eric Auger wrote: > From: "Liu, Yi L" > > This patch adds VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE ioctl > which aims to pass/withdraw the virtual iommu guest configuration > to/from the VFIO driver downto to the iommu subsystem. > > Signed-off-by: Jacob Pan >

Re: [PATCH v8 25/29] vfio-pci: Add a new VFIO_REGION_TYPE_NESTED region type

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:10:00 +0200 Eric Auger wrote: > This patch adds two new regions aiming to handle nested mode > translation faults. > > The first region (two host kernel pages) is read-only from the > user-space perspective. The first page contains an header > that provides information

Re: [PATCH v8 26/29] vfio-pci: Register an iommu fault handler

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:10:01 +0200 Eric Auger wrote: > This patch registers a fault handler which records faults in > a circular buffer and then signals an eventfd. This buffer is > exposed within the fault region. > > Signed-off-by: Eric Auger > > --- > > v3 -> v4: > - move

Re: [PATCH v8 05/29] iommu: Add a timeout parameter for PRQ response

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:09:40 +0200 Eric Auger wrote: > From: Jacob Pan > > When an IO page request is processed outside IOMMU subsystem, response > can be delayed or lost. Add a tunable setup parameter such that user can > choose the timeout for IOMMU to track pending page requests. > > This

Re: [PATCH v8 04/29] iommu: Add recoverable fault reporting

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:09:39 +0200 Eric Auger wrote: > From: Jean-Philippe Brucker > > Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall, > enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page > Requests and Stall events through the new fault

Re: [PATCH v8 28/29] vfio-pci: Add VFIO_PCI_DMA_FAULT_IRQ_INDEX

2019-06-03 Thread Alex Williamson
On Sun, 26 May 2019 18:10:03 +0200 Eric Auger wrote: > Add a new VFIO_PCI_DMA_FAULT_IRQ_INDEX index. This allows to > set/unset an eventfd that will be triggered when DMA translation > faults are detected at physical level when the nested mode is used. > > Signed-off-by: Eric Auger > --- >

Re: [PATCH v2 2/4] iommu: Introduce device fault data

2019-06-03 Thread Jacob Pan
On Mon, 3 Jun 2019 15:57:47 +0100 Jean-Philippe Brucker wrote: > +/** > + * struct iommu_fault_page_request - Page Request data > + * @flags: encodes whether the corresponding fields are valid and > whether this > + * is the last page in group (IOMMU_FAULT_PAGE_REQUEST_* > values) > + *

Re: [PATCH v2 0/4] iommu: Add device fault reporting API

2019-06-03 Thread Jacob Pan
On Mon, 3 Jun 2019 15:57:45 +0100 Jean-Philippe Brucker wrote: > Allow device drivers and VFIO to get notified on IOMMU translation > fault, and handle recoverable faults (PCI PRI). Several series require > this API (Intel VT-d and Arm SMMUv3 nested support, as well as the > generic host SVA

Re: [PATCH 07/26] iommu/dma: move the arm64 wrappers to common code

2019-06-03 Thread Jon Hunter
On 29/04/2019 13:56, Robin Murphy wrote: > On 22/04/2019 18:59, Christoph Hellwig wrote: >> There is nothing really arm64 specific in the iommu_dma_ops >> implementation, so move it to dma-iommu.c and keep a lot of symbols >> self-contained.  Note the implementation does depend on the >>

Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support

2019-06-03 Thread Clément Péron
Hi Maxime, Joerg, On Wed, 22 May 2019 at 21:27, Rob Herring wrote: > > On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote: > > > > Hi, > > > > The Allwinner H6 has a Mali-T720 MP2 which should be supported by > > the new panfrost driver. This series fix two issues and introduce the > >

Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement

2019-06-03 Thread Andreas Färber
Am 31.05.19 um 19:32 schrieb Laurentiu Tudor: >> -Original Message- >> From: Andreas Färber >> Sent: Friday, May 31, 2019 8:04 PM >> >> Hello Laurentiu, >> >> Am 31.05.19 um 18:46 schrieb Laurentiu Tudor: -Original Message- From: Andreas Färber Sent: Friday, May

[PATCH v2 1/4] driver core: Add per device iommu param

2019-06-03 Thread Jean-Philippe Brucker
From: Jacob Pan DMA faults can be detected by IOMMU at device level. Adding a pointer to struct device allows IOMMU subsystem to report relevant faults back to the device driver for further handling. For direct assigned device (or user space drivers), guest OS holds responsibility to handle and

[PATCH v2 3/4] iommu: Introduce device fault report API

2019-06-03 Thread Jean-Philippe Brucker
From: Jacob Pan Traditionally, device specific faults are detected and handled within their own device drivers. When IOMMU is enabled, faults such as DMA related transactions are detected by IOMMU. There is no generic reporting mechanism to report faults back to the in-kernel device driver or

[PATCH v2 4/4] iommu: Add recoverable fault reporting

2019-06-03 Thread Jean-Philippe Brucker
Some IOMMU hardware features, for example PCI PRI and Arm SMMU Stall, enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page Requests and Stall events through the new fault reporting API. The consumer of the fault can be either an I/O page fault handler in the host, or a guest

[PATCH v2 2/4] iommu: Introduce device fault data

2019-06-03 Thread Jean-Philippe Brucker
From: Jacob Pan Device faults detected by IOMMU can be reported outside the IOMMU subsystem for further processing. This patch introduces a generic device fault data structure. The fault can be either an unrecoverable fault or a page request, also referred to as a recoverable fault. We only

[PATCH v2 0/4] iommu: Add device fault reporting API

2019-06-03 Thread Jean-Philippe Brucker
Allow device drivers and VFIO to get notified on IOMMU translation fault, and handle recoverable faults (PCI PRI). Several series require this API (Intel VT-d and Arm SMMUv3 nested support, as well as the generic host SVA implementation). Changes since v1 [1]: * Allocate iommu_param earlier, in

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Jordan Crouse
> It shouldn't be a problem to hook something else up to the IOMMU > subsystem. Hopefully it's something that people are going to standardize > on. > > > 3) The automatic attach of DMA domain is also causing a different > >problem for us on the GPU side, preventing us from supporting per- > >

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 07:20:14AM -0700, Rob Clark wrote: > On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding > wrote: > > > > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote: > > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > > > > > > > On 03/06/2019 11:47, Rob Clark wrote: >

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding wrote: > > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote: > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > > > > > On 03/06/2019 11:47, Rob Clark wrote: > > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > > >> > > >

[PATCH -next] iommu/intel: silence a variable set but not used

2019-06-03 Thread Qian Cai
The commit "iommu/vt-d: Probe DMA-capable ACPI name space devices" introduced a compilation warning due to the "iommu" variable in for_each_active_iommu() but never used the for each element, i.e, "drhd->iommu". drivers/iommu/intel-iommu.c: In function 'probe_acpi_namespace_devices':

The dma-mapping for-next tree has been rebased

2019-06-03 Thread Christoph Hellwig
I want to pull in the cache maintainance fix for the dma-iommu conversion. Hope it didn't cause any inconvenience. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote: > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > > > On 03/06/2019 11:47, Rob Clark wrote: > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > >> > > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > >>> > > >>>

Re: [PATCH] iommu: replace single-char identifiers in macros

2019-06-03 Thread Robin Murphy
On 03/06/2019 14:29, Qian Cai wrote: On Mon, 2019-06-03 at 14:07 +0100, Robin Murphy wrote: On 03/06/2019 13:59, Qian Cai wrote: There are a few macros in IOMMU have single-char identifiers make the code hard to read and debug. Replace them with meaningful names. Suggested-by: Andrew Morton

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 12:14:27PM +0100, Robin Murphy wrote: > On 03/06/2019 11:47, Rob Clark wrote: > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > > > > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > > > > > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > > > >

Re: [PATCH] iommu: replace single-char identifiers in macros

2019-06-03 Thread Qian Cai
On Mon, 2019-06-03 at 14:07 +0100, Robin Murphy wrote: > On 03/06/2019 13:59, Qian Cai wrote: > > There are a few macros in IOMMU have single-char identifiers make the > > code hard to read and debug. Replace them with meaningful names. > > > > Suggested-by: Andrew Morton > > Signed-off-by: Qian

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote: > > On 03/06/2019 11:47, Rob Clark wrote: > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > >> > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > >>> > >>> So, another case I've come across, on the display side.. I'm working > >>> on

Re: [PATCH] iommu: replace single-char identifiers in macros

2019-06-03 Thread Robin Murphy
On 03/06/2019 13:59, Qian Cai wrote: There are a few macros in IOMMU have single-char identifiers make the code hard to read and debug. Replace them with meaningful names. Suggested-by: Andrew Morton Signed-off-by: Qian Cai --- include/linux/dmar.h | 14 -- 1 file changed, 8

[PATCH] iommu: replace single-char identifiers in macros

2019-06-03 Thread Qian Cai
There are a few macros in IOMMU have single-char identifiers make the code hard to read and debug. Replace them with meaningful names. Suggested-by: Andrew Morton Signed-off-by: Qian Cai --- include/linux/dmar.h | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH v3] iommu/arm-smmu: Avoid constant zero in TLBI writes

2019-06-03 Thread Marc Gonzalez
From: Robin Murphy Apparently, some Qualcomm arm64 platforms which appear to expose their SMMU global register space are still, in fact, using a hypervisor to mediate it by trapping and emulating register accesses. Sadly, some deployed versions of said trapping code have bugs wherein they go

Re: [PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options

2019-06-03 Thread Sebastian Ott
On Thu, 30 May 2019, Zhen Lei wrote: > The default DMA mode is LAZY on s390, this patch make it can be set to > STRICT at build time. It can be overridden by boot option. > > There is no functional change. > > Signed-off-by: Zhen Lei Acked-by: Sebastian Ott

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Vivek Gautam
On Mon, Jun 3, 2019 at 4:47 PM Christoph Hellwig wrote: > > If you (and a few others actors in the thread) want people to actually > read what you wrote please follow proper mailing list ettiquette. I've > given up on reading all the recent mails after scrolling through two > pages of full

Re: [PATCH v3 0/4] iommu/amd: Convert the AMD iommu driver to the dma-iommu api

2019-06-03 Thread Tom Murphy via iommu
On Mon, Jun 3, 2019 at 11:52 AM Joerg Roedel wrote: > > Hi Tom, > > On Mon, May 06, 2019 at 07:52:02PM +0100, Tom Murphy wrote: > > Convert the AMD iommu driver to the dma-iommu api. Remove the iova > > handling and reserve region code from the AMD iommu driver. > > Thank you for your work on

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Christoph Hellwig
If you (and a few others actors in the thread) want people to actually read what you wrote please follow proper mailing list ettiquette. I've given up on reading all the recent mails after scrolling through two pages of full quotes. ___ iommu mailing

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Robin Murphy
On 03/06/2019 11:47, Rob Clark wrote: On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: On Sat, Dec 1, 2018 at 10:54 AM Rob Clark

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Vivek Gautam
On Mon, Jun 3, 2019 at 4:14 PM Rob Clark wrote: > > On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam > wrote: > > > > > > > > On 6/3/2019 11:50 AM, Tomasz Figa wrote: > > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > >>> On Tue, Dec

Re: [PATCH v3 0/4] iommu/amd: Convert the AMD iommu driver to the dma-iommu api

2019-06-03 Thread Joerg Roedel
Hi Tom, On Mon, May 06, 2019 at 07:52:02PM +0100, Tom Murphy wrote: > Convert the AMD iommu driver to the dma-iommu api. Remove the iova > handling and reserve region code from the AMD iommu driver. Thank you for your work on this! I appreciate that much, but I am not sure we are ready to make

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote: > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > > > > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > > > > > > > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: > > >

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Mon, Jun 3, 2019 at 12:57 AM Vivek Gautam wrote: > > > > On 6/3/2019 11:50 AM, Tomasz Figa wrote: > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > >> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > >>> On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > On Sat, Dec 1, 2018 at

Re: [PATCH] iommu/dma: Fix condition check in iommu_dma_unmap_sg

2019-06-03 Thread Joerg Roedel
On Wed, May 29, 2019 at 01:15:32AM -0700, Nathan Chancellor wrote: > Fixes: 06d60728ff5c ("iommu/dma: move the arm64 wrappers to common code") > Link: https://github.com/ClangBuiltLinux/linux/issues/497 > Signed-off-by: Nathan Chancellor > --- > drivers/iommu/dma-iommu.c | 2 +- > 1 file

Re: [PATCH v4 0/6] iommu/ipmmu-vmsa: Suspend/resume support and assorted cleanups

2019-06-03 Thread Joerg Roedel
On Mon, May 27, 2019 at 01:52:47PM +0200, Geert Uytterhoeven wrote: > Geert Uytterhoeven (6): > iommu/ipmmu-vmsa: Link IOMMUs and devices in sysfs > iommu/ipmmu-vmsa: Prepare to handle 40-bit error addresses > iommu/ipmmu-vmsa: Make IPMMU_CTX_MAX unsigned > iommu/ipmmu-vmsa: Move num_utlbs

Re: [PATCH -next] intel-iommu: fix a variable set but not used

2019-06-03 Thread Joerg Roedel
On Fri, May 31, 2019 at 04:16:02PM -0400, Qian Cai wrote: > The commit "iommu/vt-d: Delegate the dma domain to upper layer" left an > unused variable, > > drivers/iommu/intel-iommu.c: In function 'disable_dmar_iommu': > drivers/iommu/intel-iommu.c:1652:23: warning: variable 'domain' set but > not

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Vivek Gautam
On 6/3/2019 11:50 AM, Tomasz Figa wrote: On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: This solves a problem we see with drm/msm,

[PATCH v6 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions

2019-06-03 Thread Eric Auger
Introduce a new type for reserved region. This corresponds to directly mapped regions which are known to be relaxable in some specific conditions, such as device assignment use case. Well known examples are those used by USB controllers providing PS/2 keyboard emulation for pre-boot BIOS and early

[PATCH v6 5/7] iommu/vt-d: Handle PCI bridge RMRR device scopes in intel_iommu_get_resv_regions

2019-06-03 Thread Eric Auger
In the case the RMRR device scope is a PCI-PCI bridge, let's check the device belongs to the PCI sub-hierarchy. Fixes: 0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put callbacks") Signed-off-by: Eric Auger Reviewed-by: Lu Baolu --- v5 -> v6: - Added Lu's R-b ---

[PATCH v6 4/7] iommu/vt-d: Handle RMRR with PCI bridge device scopes

2019-06-03 Thread Eric Auger
When reading the vtd specification and especially the Reserved Memory Region Reporting Structure chapter, it is not obvious a device scope element cannot be a PCI-PCI bridge, in which case all downstream ports are likely to access the reserved memory region. Let's handle this case in

[PATCH v6 7/7] iommu/vt-d: Differentiate relaxable and non relaxable RMRRs

2019-06-03 Thread Eric Auger
Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory region type, let's report USB and GFX RMRRs as relaxable ones. We introduce a new device_rmrr_is_relaxable() helper to check whether the rmrr belongs to the relaxable category. This allows to have a finer reporting at IOMMU API level

[PATCH v6 3/7] iommu/vt-d: Introduce is_downstream_to_pci_bridge helper

2019-06-03 Thread Eric Auger
Several call sites are about to check whether a device belongs to the PCI sub-hierarchy of a candidate PCI-PCI bridge. Introduce an helper to perform that check. Signed-off-by: Eric Auger Reviewed-by: Lu Baolu --- v5 -> v6: - fix kerneldoc comment as suggested by Christoph - added Lu's R-b

switch nios2 and microblaze to use the generic uncached segement support

2019-06-03 Thread Christoph Hellwig
Hi all, can you take a look at this series? It switches niops2 and microblaze to use the generic dma layer support for uncached segements. The dma mapping for-next git tree that includes the support is available here: git://git.infradead.org/users/hch/dma-mapping.git for-next Gitweb:

[PATCH 2/2] microblaze: use the generic uncached segment support in dma-direct

2019-06-03 Thread Christoph Hellwig
Stop providing our own arch alloc/free hooks for nommu platforms and just expose the segment offset and use the generic dma-direct allocator. Signed-off-by: Christoph Hellwig --- arch/microblaze/Kconfig | 2 + arch/microblaze/mm/consistent.c | 97 +++-- 2

[PATCH v6 0/7] RMRR related fixes and enhancements

2019-06-03 Thread Eric Auger
Currently the Intel reserved region is attached to the RMRR unit and when building the list of RMRR seen by a device we link this unique reserved region without taking care of potential multiple usage of this reserved region by several devices. Also while reading the vtd spec it is unclear to me

[PATCH v6 2/7] iommu/vt-d: Duplicate iommu_resv_region objects per device list

2019-06-03 Thread Eric Auger
intel_iommu_get_resv_regions() aims to return the list of reserved regions accessible by a given @device. However several devices can access the same reserved memory region and when building the list it is not safe to use a single iommu_resv_region object, whose container is the RMRR. This

[PATCH v6 1/7] iommu: Fix a leak in iommu_insert_resv_region

2019-06-03 Thread Eric Auger
In case we expand an existing region, we unlink this latter and insert the larger one. In that case we should free the original region after the insertion. Also we can immediately return. Fixes: 6c65fb318e8b ("iommu: iommu_get_group_resv_regions") Signed-off-by: Eric Auger ---

[PATCH 1/2] nios2: use the generic uncached segment support in dma-direct

2019-06-03 Thread Christoph Hellwig
Stop providing our own arch alloc/free hooks and just expose the segment offset and use the generic dma-direct allocator. Signed-off-by: Christoph Hellwig --- arch/nios2/Kconfig| 1 + arch/nios2/include/asm/page.h | 6 -- arch/nios2/mm/dma-mapping.c | 34

Re: [PATCH 2/7] au1100fb: fix DMA API abuse

2019-06-03 Thread Christoph Hellwig
FYI, I've merged this patch into the dma-mapping tree to make progress with the generic uncached segment support for mips.

Re: [PATCH 5/7 v2] MIPS: use the generic uncached segment support in dma-direct

2019-06-03 Thread Christoph Hellwig
On Wed, May 01, 2019 at 05:13:57PM +, Paul Burton wrote: > Hi Christoph, > > On Wed, May 01, 2019 at 03:13:39PM +0200, Christoph Hellwig wrote: > > Stop providing our arch alloc/free hooks and just expose the segment > > offset instead. > > > > Signed-off-by: Christoph Hellwig > > --- > >

How to resolve an issue in swiotlb environment?

2019-06-03 Thread Yoshihiro Shimoda
Hi linux-block and iommu mailing lists, I have an issue that a USB SSD with xHCI on R-Car H3 causes "swiotlb is full" like below. [ 36.745286] xhci-hcd ee00.usb: swiotlb buffer is full (sz: 524288 bytes), total 32768 (slots), used 1338 (slots) I have investigated this issue by using

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Tomasz Figa
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote: > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote: > > > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote: > > > > > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote: > > > > > > > > This solves a problem we see with drm/msm, caused by