Re: use generic DMA mapping code in powerpc V4

Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the generic direct mapping bypass) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 21074ef03c0816ae158721a78cabe9035938 I was able to compile the kernel for the AmigaOne X1000 (Nemo

[PATCH 1/3] swiotlb: Introduce swiotlb_max_mapping_size()

From: Joerg Roedel The function returns the maximum size that can be remapped by the SWIOTLB implementation. This function will be later exposed to users through the DMA-API. Signed-off-by: Joerg Roedel --- include/linux/swiotlb.h | 5 + kernel/dma/swiotlb.c| 5 + 2 files changed,

[PATCH 3/3] virtio-blk: Consider dma_max_mapping_size() for maximum segment size

From: Joerg Roedel Segments can't be larger than the maximum DMA mapping size supported on the platform. Take that into account when setting the maximum segment size for a block device. Signed-off-by: Joerg Roedel --- drivers/block/virtio_blk.c | 10 ++ 1 file changed, 6

[PATCH 2/3] dma: Introduce dma_max_mapping_size()

From: Joerg Roedel The function returns the maximum size that can be mapped using DMA-API functions. The patch also adds the implementation for direct DMA and a new dma_map_ops pointer so that other implementations can expose their limit. Signed-off-by: Joerg Roedel ---

Re: [RFC v2] iommu/vt-d: Allow iommu_domain_alloc to allocate IOMMU_DOMAIN_DMA

Hey Jacob, > On 7 Jan 2019, at 20:04, Jacob Pan wrote: > > On Wed, 5 Dec 2018 17:19:35 + > James Sewart wrote: > >> Hey, >> >> There exists an issue in the logic used to determine domain >> association with devices. Currently the driver uses >> find_or_alloc_domain to either reuse an

Re: [PATCH 1/3] swiotlb: Export maximum allocation size

On Mon, Jan 14, 2019 at 04:59:27PM -0500, Michael S. Tsirkin wrote: > On Mon, Jan 14, 2019 at 03:49:07PM -0500, Konrad Rzeszutek Wilk wrote: > > On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote: > > > On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote: > > > > Why

Re: use generic DMA mapping code in powerpc V4

On 15 January 2019 at 2:35PM, Christoph Hellwig wrote: On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote: Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the generic direct mapping bypass) git clone git://git.infradead.org/users/hch/misc.git -b

[PATCH v7 1/7] dt-bindings: virtio-mmio: Add IOMMU description

The nature of a virtio-mmio node is discovered by the virtio driver at probe time. However the DMA relation between devices must be described statically. When a virtio-mmio node is a virtio-iommu device, it needs an "#iommu-cells" property as specified by bindings/iommu/iommu.txt. Otherwise, the

[PATCH v7 2/7] dt-bindings: virtio: Add virtio-pci-iommu node

Some systems implement virtio-iommu as a PCI endpoint. The operating system needs to discover the relationship between IOMMU and masters long before the PCI endpoint gets probed. Add a PCI child node to describe the virtio-iommu device. The virtio-pci-iommu is conceptually split between a PCI

[PATCH v7 0/7] Add virtio-iommu driver

Implement the virtio-iommu driver, following specification v0.9 [1]. This is a simple rebase onto Linux v5.0-rc2. We now use the dev_iommu_fwspec_get() helper introduced in v5.0 instead of accessing dev->iommu_fwspec, but there aren't any functional change from v6 [2]. Our current goal for

[PATCH v7 6/7] iommu/virtio: Add probe request

When the device offers the probe feature, send a probe request for each device managed by the IOMMU. Extract RESV_MEM information. When we encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell other subsystems that there is no need to map the MSI doorbell in the

[PATCH v7 5/7] iommu: Add virtio-iommu driver

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio transport without emulating page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP requests. The bulk of the code transforms calls coming from the IOMMU API into

[PATCH v7 7/7] iommu/virtio: Add event queue

The event queue offers a way for the device to report access faults from endpoints. It is implemented on virtqueue #1. Whenever the host needs to signal a fault, it fills one of the buffers offered by the guest and interrupts it. Tested-by: Bharat Bhushan Tested-by: Eric Auger Reviewed-by: Eric

[PATCH v7 4/7] PCI: OF: Initialize dev->fwnode appropriately

For PCI devices that have an OF node, set the fwnode as well. This way drivers that rely on fwnode don't need the special case described by commit f94277af03ea ("of/platform: Initialise dev->fwnode appropriately"). Acked-by: Bjorn Helgaas Signed-off-by: Jean-Philippe Brucker ---

[PATCH v7 3/7] of: Allow the iommu-map property to omit untranslated devices

In PCI root complex nodes, the iommu-map property describes the IOMMU that translates each endpoint. On some platforms, the IOMMU itself is presented as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). This isn't supported by the current OF driver, which expects all endpoints to have an IOMMU.

Re: [PATCH v5 4/8] iommu/vt-d: Aux-domain specific domain attach/detach

On Tue, 15 Jan 2019 10:10:21 +0800 Lu Baolu wrote: > Hi, > > On 1/14/19 8:26 PM, Jonathan Cameron wrote: > > On Thu, 10 Jan 2019 11:00:23 +0800 > > Lu Baolu wrote: > > > >> When multiple domains per device has been enabled by the > >> device driver, the device will tag the default PASID for

Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote: > Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the > generic direct mapping bypass) > > git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a > > git checkout

Re: [PATCH 2/3] dma: Introduce dma_max_mapping_size()

> +size_t dma_direct_max_mapping_size(struct device *dev) > +{ > + /* > + * Return the minimum of the direct DMA limit and the SWIOTLB limit. > + * Since direct DMA has no limit, it is fine to just return the SWIOTLB > + * limit. > + */ > + return

Re: [PATCH] Revert "ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()"

On Mon, Jan 14, 2019 at 04:38:20PM +, Robin Murphy wrote: > On 14/01/2019 16:09, Thierry Reding wrote: > > On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote: > > > This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3. > > > > > > That patch broke IOMMU support for

Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 15, 2019 at 02:56:34PM +0100, Christian Zigotzky wrote: > On 15 January 2019 at 2:35PM, Christoph Hellwig wrote: >> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote: >>> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the >>> generic direct

Re: [PATCH 2/3] dma: Introduce dma_max_mapping_size()

On Tue, Jan 15, 2019 at 02:37:54PM +0100, Christoph Hellwig wrote: > > +size_t dma_direct_max_mapping_size(struct device *dev) > > +{ > > + /* > > +* Return the minimum of the direct DMA limit and the SWIOTLB limit. > > +* Since direct DMA has no limit, it is fine to just return the

[PATCH v2] dma-direct: do not allocate a single page from CMA area

The addresses within a single page are always contiguous, so it's not so necessary to allocate one single page from CMA area. Since the CMA area has a limited predefined size of space, it might run out of space in some heavy use case, where there might be quite a lot CMA pages being allocated for

Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults

Hi Jean, On 1/11/19 6:46 PM, Jean-Philippe Brucker wrote: > On 08/01/2019 10:26, Eric Auger wrote: >> When a stage 1 related fault event is read from the event queue, >> let's propagate it to potential external fault listeners, ie. users >> who registered a fault handler. >> >> Signed-off-by:

Re: [RFC v3 14/21] iommu: introduce device fault data

Hi Jean, On 1/11/19 12:06 PM, Jean-Philippe Brucker wrote: > On 10/01/2019 18:45, Jacob Pan wrote: >> On Tue, 8 Jan 2019 11:26:26 +0100 >> Eric Auger wrote: >> >>> From: Jacob Pan >>> >>> Device faults detected by IOMMU can be reported outside IOMMU >>> subsystem for further processing. This

Re: [RFC v3 04/21] vfio: VFIO_IOMMU_SET_PASID_TABLE

Hi Alex, On 1/11/19 11:50 PM, Alex Williamson wrote: > On Tue, 8 Jan 2019 11:26:16 +0100 > Eric Auger wrote: > >> From: "Liu, Yi L" >> >> This patch adds VFIO_IOMMU_SET_PASID_TABLE ioctl which aims at >> passing the virtual iommu guest configuration to the VFIO driver >> downto to the iommu

Re: [RFC v3 18/21] vfio-pci: Add a new VFIO_REGION_TYPE_NESTED region type

Hi Alex, On 1/15/19 12:04 AM, Alex Williamson wrote: > On Mon, 14 Jan 2019 21:48:06 +0100 > Auger Eric wrote: > >> Hi Alex, >> >> On 1/12/19 12:58 AM, Alex Williamson wrote: >>> On Tue, 8 Jan 2019 11:26:30 +0100 >>> Eric Auger wrote: >>> This patch adds a new 64kB region aiming to

[PATCH v1] iommu/s390: Declare s390 iommu reserved regions

The s390 iommu can only allow DMA transactions between the zPCI device entries start_dma and end_dma. Let's declare the regions before start_dma and after end_dma as reserved regions using the appropriate callback in iommu_ops. Signed-off-by: Pierre Morel --- drivers/iommu/s390-iommu.c | 29

[PATCH v1] iommu/s390: Declare s390 iommu reserved regions

The s390 iommu can only allow DMA transactions between the zPCI device entries start_dma and end_dma. Let's declare the regions before start_dma and after end_dma as reserved regions using the appropriate callback in iommu_ops. The reserved region may later be retrieved from sysfs or from the

Re: use generic DMA mapping code in powerpc V4

Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use the dma-direct allocator for coherent platforms) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28 Link to the Git:

Re: [PATCH 0/3] Fix virtio-blk issue with SWIOTLB

On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote: > Which would be fine especially if we can manage not to introduce a bunch > of indirect calls all over the place and hurt performance. Which indirect calls? In case of unset dma_ops the DMA-API functions call directly into the

Re: use generic DMA mapping code in powerpc V4

Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use the dma_direct mapping routines) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f Error message: arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0):