Re: [PATCH V6 1/3] iommu: Add support to change default domain of an iommu group

2020-09-04 Thread Joerg Roedel
On Fri, Sep 04, 2020 at 07:11:07PM +, Prakhya, Sai Praneeth wrote: > But couple of questions.. > 1. Do you want me to post the entire patch series? (i.e. 3 patches) or do you > want me to post just this patch i.e. 1st patch only > 2. Do you want me to bump the version number? i.e. post it as

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Borislav Petkov
On Fri, Sep 04, 2020 at 08:47:04PM +, Fenghua Yu wrote: > Please let me know any comments and I'll address them ASAP. I'm just > eager to see the patches upstreamed:) Why are you eager to see them upstream? What's with all that hurry everytime? -- Regards/Gruss, Boris.

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Fenghua Yu
Hi, Boris, On Fri, Sep 04, 2020 at 09:45:19PM +0200, Borislav Petkov wrote: > On Fri, Sep 04, 2020 at 04:06:13PM +, Fenghua Yu wrote: > > Thank you very much for your review! > > I'm not done with my review yet. > > > Could you please consider to commit the series? > > Fenghua, how long

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Borislav Petkov
On Fri, Sep 04, 2020 at 04:06:13PM +, Fenghua Yu wrote: > Thank you very much for your review! I'm not done with my review yet. > Could you please consider to commit the series? Fenghua, how long are you doing kernel development? When do patches get considered for inclusion? I'm sure you

RE: [PATCH V6 1/3] iommu: Add support to change default domain of an iommu group

2020-09-04 Thread Prakhya, Sai Praneeth
Hi Joerg, > -Original Message- > From: Joerg Roedel > Sent: Friday, September 4, 2020 1:31 AM > To: Prakhya, Sai Praneeth > Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj, > Ashok ; Will Deacon ; Lu Baolu > ; Mehta, Sohil ; Robin > Murphy ; Jacob Pan > Subject: Re:

Re: [PATCH 00/20] iommu/arm-smmu + drm/msm: per-process GPU pgtables

2020-09-04 Thread Rob Clark
On Fri, Sep 4, 2020 at 2:11 AM Joerg Roedel wrote: > > On Mon, Aug 17, 2020 at 03:01:25PM -0700, Rob Clark wrote: > > Jordan Crouse (12): > > iommu/arm-smmu: Pass io-pgtable config to implementation specific > > function > > iommu/arm-smmu: Add support for split pagetables > >

Re: [PATCH v3 0/6] Add virtio-iommu built-in topology

2020-09-04 Thread Auger Eric
Hi, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new

Re: [PATCH v3 2/6] iommu/virtio: Add topology helpers

2020-09-04 Thread Auger Eric
Hi Jean, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > To support topology description from ACPI and from the builtin > description, add helpers to keep track of I/O topology descriptors. > > To ease re-use of the helpers by other drivers and future ACPI > extensions, use the "virt_" prefix

Re: [PATCH v16 20/20] arm: dts: qcom: sc7180: Set the compatible string for the GPU SMMU

2020-09-04 Thread Bjorn Andersson
On Tue 01 Sep 11:46 CDT 2020, Rob Clark wrote: > From: Rob Clark > > Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable > split pagetables and per-instance pagetables for drm/msm. > Reviewed-by: Bjorn Andersson > Signed-off-by: Rob Clark > --- >

Re: [PATCH v16 19/20] arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU

2020-09-04 Thread Bjorn Andersson
On Tue 01 Sep 11:46 CDT 2020, Rob Clark wrote: > From: Jordan Crouse > > Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable > split pagetables and per-instance pagetables for drm/msm. > > Signed-off-by: Jordan Crouse > Signed-off-by: Rob Clark Reviewed-by: Bjorn Andersson

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Fenghua Yu
Hi, Boris, On Fri, Sep 04, 2020 at 12:46:14PM +0200, Borislav Petkov wrote: > Just a nitpick in case you have to send a new version or the committer > of this one can fixup the prefix here: > > > Subject: Re: [PATCH v7 1/9] iommu: Change type of pasid to u32 > > drm, iommu: Change

Re: [PATCH v3 5/6] iommu/virtio: Support topology description in config space

2020-09-04 Thread Auger Eric
Hi Jean, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Platforms without device-tree nor ACPI can provide a topology > description embedded into the virtio config space. Parse it. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA

[PATCH v3 5/8] iommu/arm-smmu-qcom: Consistently initialize stream mappings

2020-09-04 Thread Bjorn Andersson
Firmware that traps writes to S2CR to translate BYPASS into FAULT also ignores writes of type FAULT. As such booting with "disable_bypass" set will result in all S2CR registers left as configured by the bootloader. This has been seen to result in indeterministic results, as these mappings might

[PATCH v3 7/8] iommu/arm-smmu: Provide helper for allocating identity domain

2020-09-04 Thread Bjorn Andersson
Some platform implementations needs to be able to allocate a domain for emulating identity mappings using a context bank without translation. Provide a helper function to allocate such a domain. Signed-off-by: Bjorn Andersson --- Changes since v2: - Extracted from previous

[PATCH v3 4/8] iommu/arm-smmu-qcom: Emulate bypass by using context banks

2020-09-04 Thread Bjorn Andersson
Some firmware found on various Qualcomm platforms traps writes to S2CR of type BYPASS and writes FAULT into the register. In particular, this prevents us from marking the streams for the display controller as BYPASS to allow continued scanout of the screen through the initialization of the ARM

[PATCH v3 1/8] iommu/arm-smmu: Refactor context bank allocation

2020-09-04 Thread Bjorn Andersson
Extract the conditional invocation of the platform defined alloc_context_bank() to a separate function to keep arm_smmu_init_domain_context() cleaner. Instead pass a reference to the arm_smmu_device as parameter to the call. Also remove the count parameter, as this can be read from the newly

[PATCH v3 6/8] iommu/arm-smmu: Add impl hook for inherit boot mappings

2020-09-04 Thread Bjorn Andersson
Add a new operation to allow platform implementations to inherit any stream mappings from the boot loader. Signed-off-by: Bjorn Andersson --- Changes since v2: - New patch/interface drivers/iommu/arm/arm-smmu/arm-smmu.c | 11 ++- drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 ++ 2

Re: [PATCH v16 14/20] iommu/arm-smmu: Prepare for the adreno-smmu implementation

2020-09-04 Thread Bjorn Andersson
On Tue 01 Sep 11:46 CDT 2020, Rob Clark wrote: > From: Jordan Crouse > > Do a bit of prep work to add the upcoming adreno-smmu implementation. > > Add an hook to allow the implementation to choose which context banks > to allocate. > > Move some of the common structs to arm-smmu.h in

[PATCH v3 3/8] iommu/arm-smmu: Consult context bank allocator for identify domains

2020-09-04 Thread Bjorn Andersson
For implementations of the ARM SMMU where stream mappings of bypass type are prohibited identity domains can be implemented by using context banks with translation disabled. Postpone the decision to skip allocating a context bank until the implementation specific context bank allocator has been

[PATCH v3 2/8] iommu/arm-smmu: Delay modifying domain during init

2020-09-04 Thread Bjorn Andersson
Delay modifications to the domain during arm_smmu_init_domain_context() until we've allocated a context bank. This will allow us to postpone the special handling of identity domains until the platform specific context bank allocator has been executed, in a later patch. Signed-off-by: Bjorn

[PATCH v3 8/8] iommu/arm-smmu-qcom: Setup identity domain for boot mappings

2020-09-04 Thread Bjorn Andersson
With many Qualcomm platforms not having functional S2CR BYPASS a temporary IOMMU domain, without translation, needs to be allocated in order to allow these memory transactions. Unfortunately the boot loader uses the first few context banks, so rather than overwriting a active bank the last

[PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings

2020-09-04 Thread Bjorn Andersson
Based on previous attempts and discussions this is the latest attempt at inheriting stream mappings set up by the bootloader, for e.g. boot splash or efifb. Per Will's request this builds on the work by Jordan and Rob for the Adreno SMMU support. It applies cleanly ontop of v16 of their series,

Re: [PATCH v3 4/6] iommu/virtio: Add topology definitions

2020-09-04 Thread Auger Eric
Hi Jean, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Add struct definitions for describing endpoints managed by the > virtio-iommu. When VIRTIO_IOMMU_F_TOPOLOGY is offered, an array of > virtio_iommu_topo_* structures in config space describes the endpoints, > identified either by their

Re: [PATCH v3 1/6] iommu/virtio: Move to drivers/iommu/virtio/

2020-09-04 Thread Auger Eric
Hi Jean, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Before adding new files to the virtio-iommu driver, move it to its own > subfolder, similarly to other IOMMU drivers. > > Signed-off-by: Jean-Philippe Brucker > --- > drivers/iommu/Makefile| 3 +-- >

Re: [PATCH 1/3] iommu: amd: Fix kerneldoc

2020-09-04 Thread Bjorn Andersson
On Tue 28 Jul 12:08 CDT 2020, Krzysztof Kozlowski wrote: > Fix W=1 compile warnings (invalid kerneldoc): > > drivers/iommu/amd/init.c:1586: warning: Function parameter or member > 'ivrs' not described in 'get_highest_supported_ivhd_type' > drivers/iommu/amd/init.c:1938: warning:

Re: [PATCH 2/3] iommu: intel: Drop kerneldoc marker from regular comment

2020-09-04 Thread Bjorn Andersson
On Tue 28 Jul 12:08 CDT 2020, Krzysztof Kozlowski wrote: > Fix W=1 compile warnings (invalid kerneldoc): > > drivers/iommu/intel/dmar.c:389: warning: Function parameter or member > 'header' not described in 'dmar_parse_one_drhd' > Reviewed-by: Bjorn Andersson > Signed-off-by: Krzysztof

Re: [PATCH 3/3] iommu: qcom: Drop of_match_ptr to fix -Wunused-const-variable

2020-09-04 Thread Bjorn Andersson
On Tue 28 Jul 12:08 CDT 2020, Krzysztof Kozlowski wrote: > The of_device_id is included unconditionally by of.h header and used > in the driver as well. Remove of_match_ptr to fix W=1 compile test > warning with !CONFIG_OF: > > drivers/iommu/qcom_iommu.c:910:34: warning:

Re: [PATCH v10 05/30] drm: etnaviv: fix common struct sg_table related issues

2020-09-04 Thread Lucas Stach
On Fr, 2020-09-04 at 15:16 +0200, Marek Szyprowski wrote: > The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function > returns the number of the created entries in the DMA address space. > However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and > dma_unmap_sg must

[PATCH v10 09/30] drm: lima: fix common struct sg_table related issues

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

[PATCH v10 06/30] drm: exynos: use common helper for a scatterlist contiguity check

2020-09-04 Thread Marek Szyprowski
Use common helper for checking the contiguity of the imported dma-buf. Signed-off-by: Marek Szyprowski Reviewed-by: Andrzej Hajda Acked-by : Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++ 1 file changed, 3 insertions(+), 20 deletions(-) diff --git

[PATCH v10 07/30] drm: exynos: fix common struct sg_table related issues

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

[PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers

2020-09-04 Thread Marek Szyprowski
Use recently introduced common wrappers operating directly on the struct sg_table objects and scatterlist page iterators to make the code a bit more compact, robust, easier to follow and copy/paste safe. No functional change, because the code already properly did all the scatterlist related

[PATCH v10 26/30] staging: tegra-vde: fix common struct sg_table related issues

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

[PATCH v10 20/30] drm: vmwgfx: fix common struct sg_table related issues

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

[PATCH v10 05/30] drm: etnaviv: fix common struct sg_table related issues

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

[PATCH v10 19/30] drm: virtio: fix common struct sg_table related issues

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

[PATCH v10 18/30] drm: v3d: fix common struct sg_table related issues

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

[PATCH v10 10/30] drm: mediatek: use common helper for a scatterlist contiguity check

2020-09-04 Thread Marek Szyprowski
Use common helper for checking the contiguity of the imported dma-buf and do this check before allocating resources, so the error path is simpler. Signed-off-by: Marek Szyprowski Reviewed-by: Robin Murphy Acked-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 28

[PATCH v10 12/30] drm: msm: fix common struct sg_table related issues

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

[PATCH v10 15/30] drm: rockchip: use common helper for a scatterlist contiguity check

2020-09-04 Thread Marek Szyprowski
Use common helper for checking the contiguity of the imported dma-buf. Signed-off-by: Marek Szyprowski Reviewed-by: Robin Murphy --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git

[PATCH v10 22/30] xen: gntdev: fix common struct sg_table related issues

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

[PATCH v10 29/30] media: pci: fix common ALSA DMA-mapping related codes

2020-09-04 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 v10 25/30] dmabuf: fix common struct sg_table related issues

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

[PATCH v10 03/30] drm: core: fix common struct sg_table related issues

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

[PATCH v10 28/30] samples: vfio-mdev/mbochs: fix common struct sg_table related issues

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

[PATCH v10 27/30] rapidio: fix common struct sg_table related issues

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

[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-09-04 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 v10 13/30] drm: omapdrm: use common helper for extracting pages array

2020-09-04 Thread Marek Szyprowski
Use common helper for converting a sg_table object into struct page pointer array. Signed-off-by: Marek Szyprowski Reviewed-by: Robin Murphy --- drivers/gpu/drm/omapdrm/omap_gem.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git

[PATCH v10 17/30] drm: tegra: fix common struct sg_table related issues

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

[PATCH v10 08/30] drm: i915: fix common struct sg_table related issues

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

[PATCH v10 24/30] drm: rcar-du: fix common struct sg_table related issues

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

[PATCH v10 23/30] drm: host1x: fix common struct sg_table related issues

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

[PATCH v10 16/30] drm: rockchip: fix common struct sg_table related issues

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

[PATCH v10 11/30] drm: mediatek: use common helper for extracting pages array

2020-09-04 Thread Marek Szyprowski
Use common helper for converting a sg_table object into struct page pointer array. Signed-off-by: Marek Szyprowski Reviewed-by: Robin Murphy Acked-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git

[PATCH v10 04/30] drm: armada: fix common struct sg_table related issues

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

[PATCH v10 14/30] drm: panfrost: fix common struct sg_table related issues

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

[PATCH v10 21/30] drm: xen: fix common struct sg_table related issues

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

[PATCH v10 01/30] drm: prime: add common helper to check scatterlist contiguity

2020-09-04 Thread Marek Szyprowski
It is a common operation done by DRM drivers to check the contiguity of the DMA-mapped buffer described by a scatterlist in the sg_table object. Let's add a common helper for this operation. Signed-off-by: Marek Szyprowski Reviewed-by: Andrzej Hajda Reviewed-by: Robin Murphy ---

[PATCH v10 02/30] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()

2020-09-04 Thread Marek Szyprowski
Replace the current hand-crafted code for extracting pages and DMA addresses from the given scatterlist by the much more robust code based on the generic scatterlist iterators and recently introduced sg_table-based wrappers. The resulting code is simple and easy to understand, so the comment

[PATCH v2 2/4] iommu: Implement of_iommu_get_resv_regions()

2020-09-04 Thread Thierry Reding
From: Thierry Reding This is an implementation that IOMMU drivers can use to obtain reserved memory regions from a device tree node. It uses the reserved-memory DT bindings to find the regions associated with a given device. These regions will be used to create 1:1 mappings in the IOMMU domain

[RFC 4/4] iommu/tegra-smmu: Add support for reserved regions

2020-09-04 Thread Thierry Reding
From: Thierry Reding The Tegra DRM driver currently uses the IOMMU API explicitly. This means that it has fine-grained control over when exactly the translation through the IOMMU is enabled. This currently happens after the driver probes, so the driver is in a DMA quiesced state when the IOMMU

[PATCH v2 3/4] iommu: dma: Use of_iommu_get_resv_regions()

2020-09-04 Thread Thierry Reding
From: Thierry Reding For device tree nodes, use the standard of_iommu_get_resv_regions() implementation to obtain the reserved memory regions associated with a device. Cc: Rob Herring Cc: Frank Rowand Cc: devicet...@vger.kernel.org Signed-off-by: Thierry Reding --- drivers/iommu/dma-iommu.c

[PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-09-04 Thread Thierry Reding
From: Thierry Reding Reserved memory regions can be marked as "active" if hardware is expected to access the regions during boot and before the operating system can take control. One example where this is useful is for the operating system to infer whether the region needs to be identity- mapped

Re: [PATCH v5] iommu/tegra-smmu: Add locking around mapping operations

2020-09-04 Thread Joerg Roedel
On Fri, Sep 04, 2020 at 02:19:49PM +0200, Thierry Reding wrote: > Seems to work fine. Tested on Jetson TX1 with display and GPU, which are > the primary users of the SMMU. > > Tested-by: Thierry Reding > Acked-by: Thierry Reding Applied, thanks. ___

Re: [PATCH v9 14/32] drm: omapdrm: fix common struct sg_table related issues

2020-09-04 Thread Marek Szyprowski
Hi again, On 04.09.2020 14:06, Marek Szyprowski wrote: > Hi Tomi, > > On 02.09.2020 10:00, Tomi Valkeinen wrote: >> On 01/09/2020 22:33, Robin Murphy wrote: >>> On 2020-08-26 07:32, Marek Szyprowski wrote: The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function

Re: [PATCH RESEND v3] iommu/tegra-smmu: Add missing locks around mapping operations

2020-09-04 Thread Thierry Reding
On Fri, Sep 04, 2020 at 11:05:19AM +0200, Joerg Roedel wrote: > On Fri, Aug 14, 2020 at 07:22:52PM +0300, Dmitry Osipenko wrote: > > The mapping operations of the Tegra SMMU driver are subjected to a race > > condition issues because SMMU Address Space isn't allocated and freed > > atomically,

Re: [PATCH v5] iommu/tegra-smmu: Add locking around mapping operations

2020-09-04 Thread Thierry Reding
On Tue, Sep 01, 2020 at 11:37:30PM +0300, Dmitry Osipenko wrote: > The mapping operations of the Tegra SMMU driver are subjected to a race > condition issues because SMMU Address Space isn't allocated and freed > atomically, while it should be. This patch makes the mapping operations > atomic, it

Re: [PATCH v9 14/32] drm: omapdrm: fix common struct sg_table related issues

2020-09-04 Thread Marek Szyprowski
Hi Tomi, On 02.09.2020 10:00, Tomi Valkeinen wrote: > On 01/09/2020 22:33, Robin Murphy wrote: >> On 2020-08-26 07:32, Marek Szyprowski wrote: >>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function >>> returns the number of the created entries in the DMA address space. >>>

[PATCH] iommu/sun50i: Fix set-but-not-used variable warning

2020-09-04 Thread Joerg Roedel
From: Joerg Roedel Fix the following warning the the SUN50I driver: drivers/iommu/sun50i-iommu.c: In function 'sun50i_iommu_irq': drivers/iommu/sun50i-iommu.c:890:14: warning: variable 'iova' set but not used [-Wunused-but-set-variable] 890 | phys_addr_t iova; |

Re: [RESEND PATCHv5] iommu/mediatek: check 4GB mode by reading infracfg

2020-09-04 Thread Joerg Roedel
On Fri, Sep 04, 2020 at 06:40:38PM +0800, Miles Chen wrote: > In previous discussion [1] and [2], we found that it is risky to > use max_pfn or totalram_pages to tell if 4GB mode is enabled. > > Check 4GB mode by reading infracfg register, remove the usage > of the un-exported symbol max_pfn. >

Re: [PATCH v7 1/9] iommu: Change type of pasid to u32

2020-09-04 Thread Borislav Petkov
Just a nitpick in case you have to send a new version or the committer of this one can fixup the prefix here: > Subject: Re: [PATCH v7 1/9] iommu: Change type of pasid to u32 drm, iommu: Change type ... On Thu, Aug 27, 2020 at 08:06:26AM -0700, Fenghua Yu wrote: > PASID is

[RESEND PATCHv5] iommu/mediatek: check 4GB mode by reading infracfg

2020-09-04 Thread Miles Chen
In previous discussion [1] and [2], we found that it is risky to use max_pfn or totalram_pages to tell if 4GB mode is enabled. Check 4GB mode by reading infracfg register, remove the usage of the un-exported symbol max_pfn. This is a step towards building mtk_iommu as a kernel module. [1]

Re: [PATCH v5] iommu/mediatek: check 4GB mode by reading infracfg

2020-09-04 Thread Miles Chen
On Fri, 2020-09-04 at 11:42 +0200, Joerg Roedel wrote: > On Mon, Aug 31, 2020 at 06:56:39PM +0800, Miles Chen wrote: > > In previous discussion [1] and [2], we found that it is risky to > > use max_pfn or totalram_pages to tell if 4GB mode is enabled. > > > > Check 4GB mode by reading infracfg

Re: [PATCH] iommu/intel: Handle 36b addressing for x86-32

2020-09-04 Thread Joerg Roedel
On Sat, Aug 22, 2020 at 05:02:09PM +0100, Chris Wilson wrote: > Beware that the address size for x86-32 may exceed unsigned long. > > [0.368971] UBSAN: shift-out-of-bounds in > drivers/iommu/intel/iommu.c:128:14 > [0.369055] shift exponent 36 is too large for 32-bit type 'long unsigned

Re: [PATCH v1] iommu/vt-d: Move intel_iommu_gfx_mapped to Intel IOMMU header

2020-09-04 Thread Joerg Roedel
On Fri, Aug 28, 2020 at 07:12:11PM +0300, Andy Shevchenko wrote: > Static analyzer is not happy about intel_iommu_gfx_mapped declaration: > > .../drivers/iommu/intel/iommu.c:364:5: warning: symbol > 'intel_iommu_gfx_mapped' was not declared. Should it be static? > > Move its declaration to

Re: [PATCH] iommu/iova: Replace cmpxchg with xchg in queue_iova

2020-09-04 Thread Joerg Roedel
Hi Robin, On Fri, Sep 04, 2020 at 10:58:14AM +0100, Robin Murphy wrote: > On 2020-09-04 10:37, Joerg Roedel wrote: > > Adding Robin. > > Did you miss that I've reviewed this already? :) > > https://lore.kernel.org/linux-iommu/3afcc7b2-0bfb-b79c-513f-1beb66c5f...@arm.com/ Hmm, that mail wasn't

Re: [PATCH 0/2] iommu/amd: Fix IOMMUv2 devices when SME is active

2020-09-04 Thread Joerg Roedel
On Fri, Aug 28, 2020 at 03:47:07PM +, Deucher, Alexander wrote: > Ah, right, So CZ and ST are not an issue. Raven is paired with Zen based > CPUs. Okay, so for the Raven case, can you add code to the amdgpu driver which makes it fail to initialize on Raven when SME is active? There is a

Re: [PATCH V2 0/5] Convert the intel iommu driver to the dma-iommu api

2020-09-04 Thread Joerg Roedel
Hey Tom, On Thu, Sep 03, 2020 at 09:18:32PM +0100, Tom Murphy wrote: > Tom Murphy (5): > iommu: Handle freelists when using deferred flushing in iommu drivers > iommu: Add iommu_dma_free_cpu_cached_iovas function > iommu: allow the dma-iommu api to use bounce buffers > iommu/vt-d: Convert

Re: [PATCH] iommu/iova: Replace cmpxchg with xchg in queue_iova

2020-09-04 Thread Robin Murphy
Hi Joerg, On 2020-09-04 10:37, Joerg Roedel wrote: Adding Robin. Did you miss that I've reviewed this already? :) https://lore.kernel.org/linux-iommu/3afcc7b2-0bfb-b79c-513f-1beb66c5f...@arm.com/ Robin. On Thu, Aug 27, 2020 at 04:43:54PM +0800, Shaokun Zhang wrote: From: Yuqi Jin The

Re: [PATCH] iommu/dma: Remove broken huge page handling

2020-09-04 Thread Joerg Roedel
On Thu, Sep 03, 2020 at 12:34:04PM +0100, Robin Murphy wrote: > The attempt to handle huge page allocations was originally added since > the comments around stripping __GFP_COMP in other implementations were > nonsensical, and we naively assumed that split_huge_page() could simply > be called

Re: [PATCH 0/2 v2] iommu: amd: Fix intremap IO_PAGE_FAULT for VMs

2020-09-04 Thread Joerg Roedel
On Thu, Sep 03, 2020 at 09:38:20AM +, Suravee Suthikulpanit wrote: > Suravee Suthikulpanit (2): > iommu: amd: Restore IRTE.RemapEn bit after programming IRTE > iommu: amd: Use cmpxchg_double() when updating 128-bit IRTE Applied both for v5.9, thanks Suravee.

Re: [PATCH 1/1] iommu/vt-d: Fix NULL pointer dereference in dev_iommu_priv_set()

2020-09-04 Thread Joerg Roedel
On Thu, Sep 03, 2020 at 02:51:32PM +0800, Lu Baolu wrote: > --- > drivers/iommu/intel/iommu.c | 100 > 1 file changed, 55 insertions(+), 45 deletions(-) Applied for v5.9, thanks. ___ iommu mailing list

Re: [PATCH v5] iommu/mediatek: check 4GB mode by reading infracfg

2020-09-04 Thread Joerg Roedel
On Mon, Aug 31, 2020 at 06:56:39PM +0800, Miles Chen wrote: > In previous discussion [1] and [2], we found that it is risky to > use max_pfn or totalram_pages to tell if 4GB mode is enabled. > > Check 4GB mode by reading infracfg register, remove the usage > of the un-exported symbol max_pfn. >

Re: [PATCH v3 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

2020-09-04 Thread Joerg Roedel
On Fri, Aug 28, 2020 at 08:06:15AM +0800, Lu Baolu wrote: > The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General > Description) that: > > If multiple control fields in this register need to be modified, software > must serialize the modifications through multiple writes to

Re: [PATCH] iommu/iova: Replace cmpxchg with xchg in queue_iova

2020-09-04 Thread Joerg Roedel
Adding Robin. On Thu, Aug 27, 2020 at 04:43:54PM +0800, Shaokun Zhang wrote: > From: Yuqi Jin > > The performance of the atomic_xchg is better than atomic_cmpxchg because > no comparison is required. While the value of @fq_timer_on can only be 0 > or 1. Let's use atomic_xchg instead of

Re: [PATCH 0/2] r8a7742 SoC add IPMMU support

2020-09-04 Thread Joerg Roedel
On Tue, Aug 25, 2020 at 03:18:03PM +0100, Lad Prabhakar wrote: > Hi All, > > This patch series adds IPMMU support to R8A7742 (RZ/G1H) > SoC dtsi. > > Cheers, > Prabhakar > > Lad Prabhakar (2): > dt-bindings: iommu: renesas,ipmmu-vmsa: Add r8a7742 support > ARM: dts: r8a7742: Add IPMMU DT

Re: [PATCH RESEND v3] iommu/tegra-smmu: Add missing locks around mapping operations

2020-09-04 Thread Dmitry Osipenko
04.09.2020 12:19, Dmitry Osipenko пишет: > 04.09.2020 12:05, Joerg Roedel пишет: >> On Fri, Aug 14, 2020 at 07:22:52PM +0300, Dmitry Osipenko wrote: >>> The mapping operations of the Tegra SMMU driver are subjected to a race >>> condition issues because SMMU Address Space isn't allocated and freed

Re: [PATCH v2] MAINTAINERS: update QUALCOMM IOMMU after Arm SMMU drivers move

2020-09-04 Thread Joerg Roedel
On Tue, Aug 25, 2020 at 07:38:28AM +0200, Lukas Bulwahn wrote: > Commit e86d1aa8b60f ("iommu/arm-smmu: Move Arm SMMU drivers into their own > subdirectory") moved drivers/iommu/qcom_iommu.c to > drivers/iommu/arm/arm-smmu/qcom_iommu.c amongst other moves, adjusted some > sections in MAINTAINERS,

Re: [PATCH RESEND v3] iommu/tegra-smmu: Add missing locks around mapping operations

2020-09-04 Thread Dmitry Osipenko
04.09.2020 12:05, Joerg Roedel пишет: > On Fri, Aug 14, 2020 at 07:22:52PM +0300, Dmitry Osipenko wrote: >> The mapping operations of the Tegra SMMU driver are subjected to a race >> condition issues because SMMU Address Space isn't allocated and freed >> atomically, while it should be. This patch

Re: Rename iommu_tlb_* functions to iommu_iotlb_*

2020-09-04 Thread Joerg Roedel
On Mon, Aug 17, 2020 at 10:00:49PM +0100, Tom Murphy wrote: > To keep naming consistent we should stick with *iotlb*. This patch > renames a few remaining functions. > > Signed-off-by: Tom Murphy > --- > drivers/iommu/dma-iommu.c | 2 +- > drivers/iommu/iommu.c | 4 ++-- >

Re: [PATCH 00/20] iommu/arm-smmu + drm/msm: per-process GPU pgtables

2020-09-04 Thread Joerg Roedel
On Mon, Aug 17, 2020 at 03:01:25PM -0700, Rob Clark wrote: > Jordan Crouse (12): > iommu/arm-smmu: Pass io-pgtable config to implementation specific > function > iommu/arm-smmu: Add support for split pagetables > iommu/arm-smmu: Prepare for the adreno-smmu implementation >

Re: [PATCH] dt-bindings: iommu: renesas,ipmmu-vmsa: Sort compatible string in increasing number of the SoC

2020-09-04 Thread Joerg Roedel
On Sun, Aug 09, 2020 at 08:35:27PM +0100, Lad Prabhakar wrote: > Sort the items in the compatible string list in increasing number of SoC. > > Signed-off-by: Lad Prabhakar > --- > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH 0/3] iommu/tegra-smmu: Reference count fixes

2020-09-04 Thread Joerg Roedel
On Thu, Aug 06, 2020 at 05:54:01PM +0200, Thierry Reding wrote: > Thierry Reding (3): > iommu/tegra-smmu: Set IOMMU group name > iommu/tegra-smmu: Balance IOMMU group reference count > iommu/tegra-smmu: Prune IOMMU group when it is released Applied, thanks.

Re: [PATCH 1/3] iommu: amd: Fix kerneldoc

2020-09-04 Thread Joerg Roedel
On Tue, Jul 28, 2020 at 07:08:57PM +0200, Krzysztof Kozlowski wrote: > Fix W=1 compile warnings (invalid kerneldoc): > > drivers/iommu/amd/init.c:1586: warning: Function parameter or member > 'ivrs' not described in 'get_highest_supported_ivhd_type' > drivers/iommu/amd/init.c:1938:

Re: [PATCH] iommu: amd: Add missing function prototypes to fix -Wmissing-prototypes

2020-09-04 Thread Joerg Roedel
On Mon, Jul 27, 2020 at 08:36:31PM +0200, Krzysztof Kozlowski wrote: > --- > drivers/iommu/amd/amd_iommu.h | 9 + > 1 file changed, 9 insertions(+) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH] iommu: mtk: Drop of_match_ptr to fix -Wunused-const-variable

2020-09-04 Thread Joerg Roedel
On Mon, Jul 27, 2020 at 08:18:42PM +0200, Krzysztof Kozlowski wrote: > The of_device_id is included unconditionally by of.h header and used > in the driver as well. Remove of_match_ptr to fix W=1 compile test > warning with !CONFIG_OF: > > drivers/iommu/mtk_iommu.c:833:34: warning:

Re: [PATCH V6 1/3] iommu: Add support to change default domain of an iommu group

2020-09-04 Thread Joerg Roedel
Hi Sai, On Sun, Aug 23, 2020 at 10:17:26PM -0700, Sai Praneeth Prakhya wrote: > drivers/iommu/iommu.c | 225 +- > 1 file changed, 224 insertions(+), 1 deletion(-) Can you please post this as a new and separate thread so I can grab it woth b4? Thanks,