Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Raj, Ashok
Hi Alex + Joerg, accidently missed in the Cc. On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Williamson wrote: > On Mon, 4 May 2020 21:42:16 -0700 > Ashok Raj wrote: > > > PCIe Spec recommends we can relax ACS requirement for RCIEP devices. > > > > PCIe 5.0 Specification. > > 6.12 Access

Re: [PATCH v6 17/25] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()

2020-05-05 Thread Jean-Philippe Brucker
On Mon, May 04, 2020 at 01:47:23PM -0700, Jacob Pan wrote: > > > > + arm_smmu_write_ctx_desc(smmu_domain, mm->pasid, > > > > _cd); + > > > > + arm_smmu_tlb_inv_asid(smmu_domain->smmu, > > > > smmu_mn->cd->asid); > > > > + /* TODO: invalidate ATS */ > > > > + > > > If mm release

Re: [PATCH v3 18/25] drm: rcar-du: fix common struct sg_table related issues

2020-05-05 Thread Geert Uytterhoeven
Hi Marek, On Tue, May 5, 2020 at 10:48 AM Marek Szyprowski wrote: > The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the > numer of the created entries in the DMA address space. However the > subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be > called

[PATCH v5] iommu/virtio: Use page size bitmap supported by endpoint

2020-05-05 Thread Bharat Bhushan
Different endpoint can support different page size, probe endpoint if it supports specific page size otherwise use global page sizes. Signed-off-by: Bharat Bhushan --- v4->v5: - Rebase to Linux v5.7-rc4 v3->v4: - Fix whitespace error v2->v3: - Fixed error return for incompatible endpoint -

[PATCH v3 00/25] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-05 Thread Marek Szyprowski
Dear All, During the Exynos DRM GEM rework and fixing the issues in the drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most drivers in DRM framework incorrectly use nents and orig_nents entries of the struct sg_table. In case of the most DMA-mapping implementations exchanging

[PATCH v3 04/25] drm: armada: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 19/25] dmabuf: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 24/25] samples: vfio-mdev/mbochs: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 25/25] media: pci: fix common ALSA DMA-mapping related codes

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of entries passed to dma_map_sg. The sg_table->nents

[PATCH v3 06/25] drm: exynos: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 05/25] drm: etnaviv: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 20/25] staging: ion: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 12/25] drm: rockchip: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 23/25] rapidio: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 08/25] drm: lima: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 07/25] drm: i915: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 01/25] dma-mapping: add generic helpers for mapping sgtable objects

2020-05-05 Thread Marek Szyprowski
struct sg_table is a common structure used for describing a memory buffer. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA pages (nents entry). It turned out that it was a common

[PATCH v3 03/25] drm: amdgpu: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 18/25] drm: rcar-du: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 14/25] drm: virtio: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 17/25] drm: host1x: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 15/25] drm: vmwgfx: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 02/25] drm: core: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 16/25] xen: gntdev: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 09/25] drm: msm: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 10/25] drm: panfrost: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 21/25] staging: tegra-vde: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 13/25] drm: tegra: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 22/25] misc: fastrpc: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

[PATCH v3 11/25] drm: radeon: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of the entries passed to dma_map_sg. The

Re: [PATCH v2] dma: Fix max PFN arithmetic overflow on 32 bit systems

2020-05-05 Thread Alexander Dahl
Hei hei, I would like to kindly ask about the status of this patch. On Wed, Apr 15, 2020 at 04:35:21PM +0200, Alexander Dahl wrote: > now after v5.7-rc1 is out, I would kindly ask, if anyone had time to > review this one line patch? Is anything wrong with that fix? Did it maybe not reach the

[PATCH v3 2/5] dt-bindings: display: sun8i-mixer: Allow for an iommu property

2020-05-05 Thread Maxime Ripard
The H6 mixer is attached to an IOMMU, so let's allow that property to be set in the bindings. Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v3 3/5] iommu: Add Allwinner H6 IOMMU driver

2020-05-05 Thread Maxime Ripard
The Allwinner H6 has introduced an IOMMU for a few DMA controllers, mostly video related: the display engine, the video decoders / encoders, the camera capture controller, etc. The design is pretty simple compared to other IOMMUs found in SoCs: there's a single instance, controlling all the

[PATCH v3 5/5] drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU

2020-05-05 Thread Maxime Ripard
The main DRM device is actually a virtual device so it doesn't have the iommus property, which is instead on the DMA masters, in this case the mixers. Add a call to of_dma_configure with the mixers DT node but on the DRM virtual device to configure it in the same way than the mixers.

[PATCH v3 4/5] arm64: dts: allwinner: h6: Add IOMMU

2020-05-05 Thread Maxime Ripard
Now that we have a driver for the IOMMU, let's start using it. Signed-off-by: Maxime Ripard --- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi

[PATCH v3 1/5] dt-bindings: iommu: Add Allwinner H6 IOMMU bindings

2020-05-05 Thread Maxime Ripard
The Allwinner H6 has introduced an IOMMU. Let's add a device tree binding for it. Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/iommu/allwinner,sun50i-h6-iommu.yaml | 61 + 1 file

[PATCH v3 0/5] iommu: Add Allwinner H6 IOMMU driver

2020-05-05 Thread Maxime Ripard
Hi, Here's a series adding support for the IOMMU introduced in the Allwinner H6. The driver from Allwinner hints at more SoCs using it in the future (with more masters), so we can bet on that IOMMU becoming pretty much standard in new SoCs from Allwinner. One thing I wasn't really sure about was

Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues

2020-05-05 Thread Christoph Hellwig
> - for_each_sg_page(st->sgl, _iter, st->nents, 0) > + for_each_sg_page(st->sgl, _iter, st->orig_nents, 0) Would it make sense to also add a for_each_sgtable_page helper that hides the use of orig_nents? To be used like: for_each_sgtable_page(st, _iter,

Re: [PATCH 00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"

2020-05-05 Thread André Przywara
On 05/05/2020 18:06, Robin Murphy wrote: > On 2020-05-05 5:51 pm, Andre Przywara wrote: >> Date: Mon, 4 May 2020 12:42:49 +0100 >> Subject: [PATCH 02/16] dt-bindings: arm-smmu: Allow mmu-400,smmu-v1 >> compatible > > ^^ not sure how you managed that... Impressive, huh? ;-) Actually just an

[PATCH 00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"

2020-05-05 Thread Andre Przywara
Date: Mon, 4 May 2020 12:42:49 +0100 Subject: [PATCH 02/16] dt-bindings: arm-smmu: Allow mmu-400,smmu-v1 compatible The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with arm,smmu-v1, even though the MMU-400 is compatible as well. Allow this combination as well to let the Arm Juno

Re: [PATCH 00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"

2020-05-05 Thread Robin Murphy
On 2020-05-05 5:51 pm, Andre Przywara wrote: Date: Mon, 4 May 2020 12:42:49 +0100 Subject: [PATCH 02/16] dt-bindings: arm-smmu: Allow mmu-400,smmu-v1 compatible ^^ not sure how you managed that... The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with arm,smmu-v1, even though the

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Alex Williamson
On Tue, 5 May 2020 07:56:06 -0700 "Raj, Ashok" wrote: > On Tue, May 05, 2020 at 08:05:14AM -0600, Alex Williamson wrote: > > On Mon, 4 May 2020 23:11:07 -0700 > > "Raj, Ashok" wrote: > > > > > Hi Alex > > > > > > + Joerg, accidently missed in the Cc. > > > > > > On Mon, May 04, 2020 at

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Raj, Ashok
On Tue, May 05, 2020 at 08:05:14AM -0600, Alex Williamson wrote: > On Mon, 4 May 2020 23:11:07 -0700 > "Raj, Ashok" wrote: > > > Hi Alex > > > > + Joerg, accidently missed in the Cc. > > > > On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Williamson wrote: > > > On Mon, 4 May 2020 21:42:16

Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.

2020-05-05 Thread Alex Williamson
On Mon, 4 May 2020 23:11:07 -0700 "Raj, Ashok" wrote: > Hi Alex > > + Joerg, accidently missed in the Cc. > > On Mon, May 04, 2020 at 11:19:36PM -0600, Alex Williamson wrote: > > On Mon, 4 May 2020 21:42:16 -0700 > > Ashok Raj wrote: > > > > > PCIe Spec recommends we can relax ACS

[PATCH v4 1/3] iommu/vt-d: Allow 32bit devices to uses DMA domain

2020-05-05 Thread Lu Baolu
Currently, if a 32bit device initially uses an identity domain, Intel IOMMU driver will convert it forcibly to a DMA one if its address capability is not enough for the whole system memory. The motivation was to overcome the overhead caused by possible bounced buffer. Unfortunately, this

[PATCH v4 3/3] iommu/vt-d: Apply per-device dma_ops

2020-05-05 Thread Lu Baolu
Current Intel IOMMU driver sets the system level dma_ops. This causes each dma API to go through the IOMMU driver even the devices are using identity mapped domains. This sets per-device dma_ops only if a device is using a DMA domain. Otherwise, use the default system level dma_ops for direct dma.

[PATCH v4 2/3] iommu/vt-d: Allow PCI sub-hierarchy to use DMA domain

2020-05-05 Thread Lu Baolu
Before commit fa954e6831789 ("iommu/vt-d: Delegate the dma domain to upper layer"), Intel IOMMU started off with all devices in the identity domain, and took them out later if it found they couldn't access all of memory. This required devices behind a PCI bridge to use a DMA domain at the

[PATCH v4 0/3] Replace private domain with per-group default domain

2020-05-05 Thread Lu Baolu
Some devices are required to use a specific type (identity or dma) of default domain when they are used with a vendor iommu. When the system level default domain type is different from it, the vendor iommu driver has to request a new default domain with either iommu_request_dma_domain_for_dev() or

Re: [PATCH v4 0/3] Replace private domain with per-group default domain

2020-05-05 Thread Daniel Drake
On Wed, May 6, 2020 at 10:03 AM Lu Baolu wrote: > https://lkml.org/lkml/2020/4/14/616 > [This has been applied in iommu/next.] > > Hence, there is no need to keep the private domain implementation > in the Intel IOMMU driver. This patch series aims to remove it. I applied these patches on top of

Re: [PATCH v5] iommu/virtio: Use page size bitmap supported by endpoint

2020-05-05 Thread Michael S. Tsirkin
On Tue, May 05, 2020 at 03:00:04PM +0530, Bharat Bhushan wrote: > Different endpoint can support different page size, probe > endpoint if it supports specific page size otherwise use > global page sizes. > > Signed-off-by: Bharat Bhushan > --- > v4->v5: > - Rebase to Linux v5.7-rc4 > > v3->v4:

[PATCH] iommu/virtio: reverse arguments to list_add

2020-05-05 Thread Julia Lawall
Elsewhere in the file, there is a list_for_each_entry with >resv_regions as the second argument, suggesting that >resv_regions is the list head. So exchange the arguments on the list_add call to put the list head in the second argument. Fixes: 2a5a31487445 ("iommu/virtio: Add probe request")

Re: [PATCH v5] dt-bindings: iommu: renesas,ipmmu-vmsa: convert to json-schema

2020-05-05 Thread Rob Herring
On Tue, 21 Apr 2020 14:15:52 +0900, Yoshihiro Shimoda wrote: > Convert Renesas VMSA-Compatible IOMMU bindings documentation > to json-schema. > > Note that original documentation doesn't mention renesas,ipmmu-vmsa > for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car > Gen2. So,

Re: [PATCH 0/5] iommu/amd: Fix race conditions around increase_address_space()

2020-05-05 Thread Joerg Roedel
On Mon, May 04, 2020 at 02:54:08PM +0200, Joerg Roedel wrote: > Joerg Roedel (5): > iommu/amd: Fix race in increase_address_space()/fetch_pte() > iommu/amd: Do not loop forever when trying to increase address space > iommu/amd: Call domain_flush_complete() in update_domain() > iommu/amd:

Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues

2020-05-05 Thread Christoph Hellwig
On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote: > Hi Christoph, > > On 05.05.2020 12:15, Christoph Hellwig wrote: > >> - for_each_sg_page(st->sgl, _iter, st->nents, 0) > >> + for_each_sg_page(st->sgl, _iter, st->orig_nents, 0) > > Would it make sense to also

Re: [PATCH v3 00/34] iommu: Move iommu_group setup to IOMMU core code

2020-05-05 Thread Joerg Roedel
On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote: > Please review. If there are no objections I plan to put these patches > into the IOMMU tree early next week. Series is now applied. ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues

2020-05-05 Thread Marek Szyprowski
Hi Christoph, On 05.05.2020 12:15, Christoph Hellwig wrote: >> -for_each_sg_page(st->sgl, _iter, st->nents, 0) >> +for_each_sg_page(st->sgl, _iter, st->orig_nents, 0) > Would it make sense to also add a for_each_sgtable_page helper that > hides the use of orig_nents? To

Re: [PATCH v3 01/25] dma-mapping: add generic helpers for mapping sgtable objects

2020-05-05 Thread Marek Szyprowski
Hi Christoph, On 05.05.2020 12:22, Christoph Hellwig wrote: >> +static inline int dma_map_sgtable_attrs(struct device *dev, >> +struct sg_table *sgt, enum dma_data_direction dir, unsigned long attrs) > Two tab indents for parameter continuation, please. > > Can we also skip the separate

Re: [PATCH v3 01/25] dma-mapping: add generic helpers for mapping sgtable objects

2020-05-05 Thread Christoph Hellwig
> +static inline int dma_map_sgtable_attrs(struct device *dev, > + struct sg_table *sgt, enum dma_data_direction dir, unsigned long attrs) Two tab indents for parameter continuation, please. Can we also skip the separate _attrs version? The existing ones have the separate _attrs variant as