Re: [PATCH v4 3/7] iommu/mediatek: Set MISC_CTRL register

2020-06-18 Thread chao hao
On Wed, 2020-06-17 at 11:34 +0200, Matthias Brugger wrote: > > On 17/06/2020 05:00, Chao Hao wrote: > > Add F_MMU_IN_ORDER_WR_EN definition in MISC_CTRL. > > In order to improve performance, we always disable STANDARD_AXI_MODE > > and IN_ORDER_WR_EN in MISC_CTRL. > > > > Change since v3: > >

Re: [PATCH v4 5/7] iommu/mediatek: Add sub_comm id in translation fault

2020-06-18 Thread chao hao
On Wed, 2020-06-17 at 19:11 +0800, Yong Wu wrote: > Hi Matthias, > > Thanks very much for your review. > > On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote: > > > > On 17/06/2020 05:00, Chao Hao wrote: > > > The max larb number that a iommu HW support is 8(larb0~larb7 in the below > >

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Andy Shevchenko
On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman wrote: > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig > > > wrote: > > > > ... > > > > > (and likely call it

Re: [PATCH v4 06/17] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put

2020-06-18 Thread Yong Wu
+ Rick On Sat, 2020-05-30 at 16:10 +0800, Yong Wu wrote: > MediaTek IOMMU has already added device_link between the consumer > and smi-larb device. If the jpg device call the pm_runtime_get_sync, > the smi-larb's pm_runtime_get_sync also be called automatically. > > CC: Rick Chang >

RE: [PATCH v2 02/15] iommu: Report domain nesting info

2020-06-18 Thread Liu, Yi L
Hi Jean, > From: Jean-Philippe Brucker < jean-phili...@linaro.org> > Sent: Wednesday, June 17, 2020 10:39 PM > > [+ Will and Robin] > > Hi Yi, > > On Thu, Jun 11, 2020 at 05:15:21AM -0700, Liu Yi L wrote: > > IOMMUs that support nesting translation needs report the capability > > info to

Re: [PATCH v4 7/7] iommu/mediatek: Add mt6779 basic support

2020-06-18 Thread chao hao
On Wed, 2020-06-17 at 11:33 +0200, Matthias Brugger wrote: > > On 17/06/2020 05:00, Chao Hao wrote: > > 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add > >REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it. > > 2. Change PROTECT_PA_ALIGN from 128 byte to 256 byte. > > 3. For

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 12:14:41PM +0300, Andy Shevchenko wrote: > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > > > On Wed, Jun 17, 2020 at 12:31

Re: [PATCH v3 01/13] iommu: Change type of pasid to unsigned int

2020-06-18 Thread Fenghua Yu
On Thu, Jun 18, 2020 at 12:12:06AM -0700, Christoph Hellwig wrote: > On Wed, Jun 17, 2020 at 11:23:41AM -0700, Fenghua Yu wrote: > > PASID is defined as a few different types in iommu including "int", > > "u32", and "unsigned int". To be consistent and to match with ioasid's > > type, define PASID

[PATCH v6 03/36] drm: core: fix common struct sg_table related issues

2020-06-18 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 v6 09/36] drm: i915: fix common struct sg_table related issues

2020-06-18 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 v6 30/36] staging: tegra-vde: fix common struct sg_table related issues

2020-06-18 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 v6 01/36] drm: prime: add common helper to check scatterlist contiguity

2020-06-18 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 --- drivers/gpu/drm/drm_gem_cma_helper.c | 23 +++

[PATCH v6 06/36] drm: etnaviv: fix common struct sg_table related issues

2020-06-18 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 v6 35/36] videobuf2: use sgtable-based scatterlist wrappers

2020-06-18 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 scaterlist related calls.

[PATCH v6 26/36] drm: rcar-du: fix common struct sg_table related issues

2020-06-18 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 v6 20/36] drm: tegra: fix common struct sg_table related issues

2020-06-18 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 v6 13/36] drm: msm: fix common struct sg_table related issues

2020-06-18 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 v6 23/36] drm: vmwgfx: fix common struct sg_table related issues

2020-06-18 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 v6 25/36] drm: host1x: fix common struct sg_table related issues

2020-06-18 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 v6 15/36] drm: omapdrm: fix common struct sg_table related issues

2020-06-18 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 v6 29/36] staging: ion: fix common struct sg_table related issues

2020-06-18 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 v6 18/36] drm: rockchip: use common helper for a scatterlist contiguity check

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

[PATCH v6 21/36] drm: v3d: fix common struct sg_table related issues

2020-06-18 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 v6 32/36] rapidio: fix common struct sg_table related issues

2020-06-18 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 v6 08/36] drm: exynos: fix common struct sg_table related issues

2020-06-18 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 v6 28/36] staging: ion: remove dead code

2020-06-18 Thread Marek Szyprowski
ion_heap_pages_zero() function is not used at all, so remove it to simplify the ion_heap_sglist_zero() function later. Signed-off-by: Marek Szyprowski --- drivers/staging/android/ion/ion.h | 1 - drivers/staging/android/ion/ion_heap.c | 9 - 2 files changed, 10 deletions(-) diff

[PATCH v6 17/36] drm: radeon: fix common struct sg_table related issues

2020-06-18 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 v6 27/36] dmabuf: fix common struct sg_table related issues

2020-06-18 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 v6 05/36] drm: armada: fix common struct sg_table related issues

2020-06-18 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 v6 19/36] drm: rockchip: fix common struct sg_table related issues

2020-06-18 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

Re: [Regression] Re: [PATCH 18/18] iommu/vt-d: Remove IOVA handling code from the non-dma_ops path

2020-06-18 Thread Alex Williamson
On Thu, 18 Jun 2020 09:52:56 +0800 Lu Baolu wrote: > Hi Alex, > > Thanks for the report. > > On 6/18/20 4:06 AM, Alex Williamson wrote: > > On Sat, 16 May 2020 14:21:01 +0800 > > Lu Baolu wrote: > > > >> From: Tom Murphy > >> > >> There's no need for the non-dma_ops path to keep track of

[PATCH v6 36/36] drm: xen: fix common struct sg_table related issues

2020-06-18 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 v6 14/36] drm: omapdrm: use common helper for extracting pages array

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

[PATCH v6 00/36] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-06-18 Thread Marek Szyprowski
sg_table objects exported by dmabuf related functions. I hope that I didn't break anything there. Patches are based on top of Linux next-20200618. The required changes to DMA-mapping framework has been already merged to v5.8-rc1. If possible I would like ask for merging most of the patches via

[PATCH v6 24/36] xen: gntdev: fix common struct sg_table related issues

2020-06-18 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 v6 22/36] drm: virtio: fix common struct sg_table related issues

2020-06-18 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 v6 04/36] drm: amdgpu: fix common struct sg_table related issues

2020-06-18 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 v6 16/36] drm: panfrost: fix common struct sg_table related issues

2020-06-18 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 v6 11/36] drm: mediatek: use common helper for a scatterlist contiguity check

2020-06-18 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 --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 28 ++ 1 file changed, 6 insertions(+), 22

[PATCH v6 10/36] drm: lima: fix common struct sg_table related issues

2020-06-18 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 v6 34/36] media: pci: fix common ALSA DMA-mapping related codes

2020-06-18 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 v6 33/36] samples: vfio-mdev/mbochs: fix common struct sg_table related issues

2020-06-18 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 v6 31/36] misc: fastrpc: fix common struct sg_table related issues

2020-06-18 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 v6 12/36] drm: mediatek: use common helper for extracting pages array

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

[PATCH v6 07/36] drm: exynos: use common helper for a scatterlist contiguity check

2020-06-18 Thread Marek Szyprowski
Use common helper for checking the contiguity of the imported dma-buf. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +++ 1 file changed, 3 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c

[PATCH v6 02/36] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()

2020-06-18 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

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Andy Shevchenko
On Thu, Jun 18, 2020 at 6:04 PM Rajat Jain wrote: > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > wrote: ... > To clarify, the attribute exposed by the firmware today is > "ExternalFacingPort" and "external-facing" respectively: > > 617654aae50e ("PCI / ACPI: Identify untrusted PCI

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Rajat Jain via iommu
Hello, On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko wrote: > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > > > On Wed, Jun 17, 2020 at 12:31

[PATCH v8 02/12] iommu/ioasid: Add ioasid references

2020-06-18 Thread Jean-Philippe Brucker
Let IOASID users take references to existing ioasids with ioasid_get(). ioasid_put() drops a reference and only frees the ioasid when its reference number is zero. It returns true if the ioasid was freed. For drivers that don't call ioasid_get(), ioasid_put() is the same as ioasid_free().

[PATCH v8 12/12] iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops

2020-06-18 Thread Jean-Philippe Brucker
The invalidate_range() notifier is called for any change to the address space. Perform the required ATC invalidations. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 36 1 file changed, 32 insertions(+), 4 deletions(-) diff --git

[PATCH v8 05/12] iommu/io-pgtable-arm: Move some definitions to a header

2020-06-18 Thread Jean-Philippe Brucker
Extract some of the most generic TCR defines, so they can be reused by the page table sharing code. Acked-by: Will Deacon Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/io-pgtable-arm.h | 30 ++ drivers/iommu/io-pgtable-arm.c | 27 ++-

[PATCH v8 01/12] mm: Define pasid in mm

2020-06-18 Thread Jean-Philippe Brucker
From: Fenghua Yu PASID is shared by all threads in a process. So the logical place to keep track of it is in the "mm". Both ARM and X86 need to use the PASID in the "mm". Suggested-by: Christoph Hellwig Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck ---

[PATCH v8 03/12] iommu/sva: Add PASID helpers

2020-06-18 Thread Jean-Philippe Brucker
Let IOMMU drivers allocate a single PASID per mm. Store the mm in the IOASID set to allow refcounting and searching mm by PASID, when handling an I/O page fault. Signed-off-by: Jean-Philippe Brucker --- v7->v8: rename to IOMMU_SVA_LIB (Lu Baolu) --- drivers/iommu/Kconfig | 5 +++

[PATCH v8 06/12] arm64: cpufeature: Export symbol read_sanitised_ftr_reg()

2020-06-18 Thread Jean-Philippe Brucker
The SMMUv3 driver would like to read the MMFR0 PARANGE field in order to share CPU page tables with devices. Allow the driver to be built as module by exporting the read_sanitized_ftr_reg() cpufeature symbol. Acked-by: Suzuki K Poulose Signed-off-by: Jean-Philippe Brucker ---

Re: [PATCH v2 02/12] ocxl: Change type of pasid to unsigned int

2020-06-18 Thread Fenghua Yu
Hi, Frederic, On Thu, Jun 18, 2020 at 10:05:19AM +0200, Frederic Barrat wrote: > > > Le 13/06/2020 à 02:41, Fenghua Yu a écrit : > >PASID is defined as "int" although it's a 20-bit value and shouldn't be > >negative int. To be consistent with type defined in iommu, define PASID > >as "unsigned

Re: [PATCH v4 7/7] iommu/mediatek: Add mt6779 basic support

2020-06-18 Thread Matthias Brugger
On 18/06/2020 13:54, chao hao wrote: > On Wed, 2020-06-17 at 11:33 +0200, Matthias Brugger wrote: >> >> On 17/06/2020 05:00, Chao Hao wrote: >>> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add >>>REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it. >>> 2. Change

[PATCH] dma-mapping: DMA_COHERENT_POOL should select GENERIC_ALLOCATOR

2020-06-18 Thread Christoph Hellwig
The dma coherent pool code needs genalloc. Move the select over from DMA_REMAP, which doesn't actually need it. Fixes: dbed452a078d ("dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL") Reported-by: kernel test robot --- kernel/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v8 00/12] iommu: Shared Virtual Addressing for SMMUv3 (PT sharing part)

2020-06-18 Thread Jean-Philippe Brucker
Since v7 [1], I split the series into three parts to ease review. This first one adds page table sharing to the SMMUv3 driver. The second one adds support for I/O page faults through PRI and Stall, and the last one adds additional and optional features (DVM, VHE and HTTU). SVA needs the three

[PATCH v8 09/12] iommu/arm-smmu-v3: Check for SVA features

2020-06-18 Thread Jean-Philippe Brucker
Aggregate all sanity-checks for sharing CPU page tables with the SMMU under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to check FEAT_ATS and FEAT_PRI. For platform SVA, they will have to check FEAT_STALLS. Introduce ARM_SMMU_FEAT_BTM (Broadcast TLB Maintenance), but don't

[PATCH v8 10/12] iommu/arm-smmu-v3: Add SVA device feature

2020-06-18 Thread Jean-Philippe Brucker
Implement the IOMMU device feature callbacks to support the SVA feature. At the moment dev_has_feat() returns false since I/O Page Faults isn't yet implemented. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/arm-smmu-v3.c | 124 1 file changed, 124

[PATCH v8 08/12] iommu/arm-smmu-v3: Seize private ASID

2020-06-18 Thread Jean-Philippe Brucker
The SMMU has a single ASID space, the union of shared and private ASID sets. This means that the SMMU driver competes with the arch allocator for ASIDs. Shared ASIDs are those of Linux processes, allocated by the arch, and contribute in broadcast TLB maintenance. Private ASIDs are allocated by the

[PATCH v8 04/12] arm64: mm: Pin down ASIDs for sharing mm with devices

2020-06-18 Thread Jean-Philippe Brucker
To enable address space sharing with the IOMMU, introduce mm_context_get() and mm_context_put(), that pin down a context and ensure that it will keep its ASID after a rollover. Export the symbols to let the modular SMMUv3 driver use them. Pinning is necessary because a device constantly needs a

[PATCH v8 11/12] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()

2020-06-18 Thread Jean-Philippe Brucker
The sva_bind() function allows devices to access process address spaces using a PASID (aka SSID). (1) bind() allocates or gets an existing MMU notifier tied to the (domain, mm) pair. Each mm gets one PASID. (2) Any change to the address space calls invalidate_range() which sends ATC

[PATCH v8 07/12] iommu/arm-smmu-v3: Share process page tables

2020-06-18 Thread Jean-Philippe Brucker
With Shared Virtual Addressing (SVA), we need to mirror CPU TTBR, TCR, MAIR and ASIDs in SMMU contexts. Each SMMU has a single ASID space split into two sets, shared and private. Shared ASIDs correspond to those obtained from the arch ASID allocator, and private ASIDs are used for "classic"

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > Hello, > > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > wrote: > > > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > > > > On Wed,

Re: [PATCH v2 02/12] ocxl: Change type of pasid to unsigned int

2020-06-18 Thread Frederic Barrat
Le 18/06/2020 à 17:37, Fenghua Yu a écrit : The first 3 patches clean up pasid and flag defitions to prepare for following patches. If you think this patch can be dropped, we will drop it. Yes, I think that's the case. Thanks, Fred ___ iommu

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Raj, Ashok
Hi Greg, On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote: > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > > Hello, > > > > On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko > > wrote: > > > > > > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman > > > wrote:

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Rajat Jain via iommu
Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming in. On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote: > > Hi Greg, > > > On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote: > > > Hello, >

Re: [PATCH v4 06/17] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put

2020-06-18 Thread Rick Chang
Hi Yong, On Thu, 2020-06-18 at 17:32 +0800, Yong Wu wrote: > + Rick > > On Sat, 2020-05-30 at 16:10 +0800, Yong Wu wrote: > > > > MediaTek IOMMU has already added device_link between the consumer > > and smi-larb device. If the jpg device call the > > pm_runtime_get_sync, > > the smi-larb's

Re: [PATCH] dma-mapping: DMA_COHERENT_POOL should select GENERIC_ALLOCATOR

2020-06-18 Thread David Rientjes via iommu
On Thu, 18 Jun 2020, Christoph Hellwig wrote: > The dma coherent pool code needs genalloc. Move the select over > from DMA_REMAP, which doesn't actually need it. > > Fixes: dbed452a078d ("dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL") > Reported-by: kernel test robot Acked-by: David

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 10:23:38AM -0700, Rajat Jain wrote: > Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming > in. > > On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote: > > > > Hi Greg, > > > > > > On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote:

Re: [PATCH v2 2/8] iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatibles

2020-06-18 Thread Robin Murphy
On 2020-06-09 20:40, Jonathan Marek wrote: Use the qcom implementation for IOMMU hardware on sm8150 and sm8250 SoCs. Given a promise that anyone who wants to add more of these in future converts it into an of_device_id table exported from arm-smmu-qcom, Reviewed-by Robin Murphy

Re: [PATCH v6 01/36] drm: prime: add common helper to check scatterlist contiguity

2020-06-18 Thread Robin Murphy
On 2020-06-18 16:39, Marek Szyprowski wrote: 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 ---

kernel BUG at mm/huge_memory.c:2613!

2020-06-18 Thread Roman Gushchin via iommu
Hi! I was consistently hitting a VM_BUG_ON_PAGE() in split_huge_page_to_list() when running vanilla 5.8-rc1 on my desktop. It was happening on every boot during the system start. I haven't seen this issue on 5.7. It looks like split_huge_page() expects the page to be locked, but it hasn't been

Re: kernel BUG at mm/huge_memory.c:2613!

2020-06-18 Thread Roman Gushchin via iommu
On Thu, Jun 18, 2020 at 05:46:24PM -0700, Yang Shi wrote: > On Thu, Jun 18, 2020 at 5:19 PM Roman Gushchin wrote: > > > > Hi! > > > > I was consistently hitting a VM_BUG_ON_PAGE() in split_huge_page_to_list() > > when running vanilla 5.8-rc1 on my desktop. It was happening on every boot > >

Re: [PATCH v6 32/36] rapidio: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Yet something to improve: [auto build test ERROR on next-20200618] [also build test ERROR on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7] [If your

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Rajat Jain via iommu
Hi Bjorn, All, Thank you so much for your helpful review and inputs. On Mon, Jun 15, 2020 at 6:17 PM Rajat Jain wrote: > > This is needed to allow the userspace to determine when an untrusted > device has been added, and thus allowing it to bind the driver manually > to it, if it so wishes.

Re: [PATCH v6 35/36] videobuf2: use sgtable-based scatterlist wrappers

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Yet something to improve: [auto build test ERROR on next-20200618] [also build test ERROR on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7] [If your

Re: [PATCH v6 04/36] drm: amdgpu: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20200618] [also build test WARNING on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7

Re: [PATCH v6 21/36] drm: v3d: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20200618] [also build test WARNING on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7

Re: [Regression] Re: [PATCH 18/18] iommu/vt-d: Remove IOVA handling code from the non-dma_ops path

2020-06-18 Thread Lu Baolu
Hi Alex, On 6/18/20 11:03 PM, Alex Williamson wrote: On Thu, 18 Jun 2020 09:52:56 +0800 Lu Baolu wrote: Hi Alex, Thanks for the report. On 6/18/20 4:06 AM, Alex Williamson wrote: On Sat, 16 May 2020 14:21:01 +0800 Lu Baolu wrote: From: Tom Murphy There's no need for the non-dma_ops

[PATCH 1/1] iommu/vt-d: Fix misuse of iommu_domain_identity_map()

2020-06-18 Thread Lu Baolu
The iommu_domain_identity_map() helper takes start/end PFN as arguments. Fix a misuse case where the start and end addresses are passed. Fixes: e70b081c6f376 ("iommu/vt-d: Remove IOVA handling code from the non-dma_ops path") Cc: Tom Murphy Reported-by: Alex Williamson Signed-off-by: Lu Baolu

Re: [PATCH 1/1] iommu/vt-d: Fix misuse of iommu_domain_identity_map()

2020-06-18 Thread Jerry Snitselaar
On Fri Jun 19 20, Lu Baolu wrote: The iommu_domain_identity_map() helper takes start/end PFN as arguments. Fix a misuse case where the start and end addresses are passed. Fixes: e70b081c6f376 ("iommu/vt-d: Remove IOVA handling code from the non-dma_ops path") Cc: Tom Murphy Reported-by: Alex

Re: kernel BUG at mm/huge_memory.c:2613!

2020-06-18 Thread Yang Shi
On Thu, Jun 18, 2020 at 5:19 PM Roman Gushchin wrote: > > Hi! > > I was consistently hitting a VM_BUG_ON_PAGE() in split_huge_page_to_list() > when running vanilla 5.8-rc1 on my desktop. It was happening on every boot > during the system start. I haven't seen this issue on 5.7. > > It looks like

Re: kernel BUG at mm/huge_memory.c:2613!

2020-06-18 Thread Yang Shi
On Thu, Jun 18, 2020 at 6:15 PM Roman Gushchin wrote: > > On Thu, Jun 18, 2020 at 05:46:24PM -0700, Yang Shi wrote: > > On Thu, Jun 18, 2020 at 5:19 PM Roman Gushchin wrote: > > > > > > Hi! > > > > > > I was consistently hitting a VM_BUG_ON_PAGE() in split_huge_page_to_list() > > > when running

Re: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Alex Williamson
On Wed, 17 Jun 2020 08:28:24 + "Tian, Kevin" wrote: > > From: Liu, Yi L > > Sent: Wednesday, June 17, 2020 2:20 PM > > > > > From: Jacob Pan > > > Sent: Tuesday, June 16, 2020 11:22 PM > > > > > > On Thu, 11 Jun 2020 17:27:27 -0700 > > > Jacob Pan wrote: > > > > > > > > > > > > > But

Re: kernel BUG at mm/huge_memory.c:2613!

2020-06-18 Thread Andrea Arcangeli
Hello, On Thu, Jun 18, 2020 at 06:14:49PM -0700, Roman Gushchin wrote: > I agree. The whole > > page = alloc_pages_node(nid, alloc_flags, order); > if (!page) > continue; > if (!order) > break; > if (!PageCompound(page)) { >

RE: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Friday, June 19, 2020 5:48 AM > > On Wed, 17 Jun 2020 08:28:24 + > "Tian, Kevin" wrote: > > > > From: Liu, Yi L > > > Sent: Wednesday, June 17, 2020 2:20 PM > > > > > > > From: Jacob Pan > > > > Sent: Tuesday, June 16, 2020 11:22 PM > > > > > > >

Re: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Alex Williamson
On Fri, 19 Jun 2020 02:15:36 + "Liu, Yi L" wrote: > Hi Alex, > > > From: Alex Williamson > > Sent: Friday, June 19, 2020 5:48 AM > > > > On Wed, 17 Jun 2020 08:28:24 + > > "Tian, Kevin" wrote: > > > > > > From: Liu, Yi L > > > > Sent: Wednesday, June 17, 2020 2:20 PM > > > > >

RE: [PATCH v2 1/3] docs: IOMMU user API

2020-06-18 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Friday, June 19, 2020 10:55 AM > > On Fri, 19 Jun 2020 02:15:36 + > "Liu, Yi L" wrote: > > > Hi Alex, > > > > > From: Alex Williamson > > > Sent: Friday, June 19, 2020 5:48 AM > > > > > > On Wed, 17 Jun 2020 08:28:24 + > > > "Tian, Kevin"

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-06-18 Thread Zhangfei Gao
Hi, Bjorn On 2020/6/16 上午7:52, Bjorn Helgaas wrote: On Sat, Jun 13, 2020 at 10:30:56PM +0800, Zhangfei Gao wrote: On 2020/6/11 下午9:44, Bjorn Helgaas wrote: +++ b/drivers/iommu/iommu.c @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,

Re: [PATCH v6 23/36] drm: vmwgfx: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20200618] [also build test WARNING on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7

Re: [PATCH v6 23/36] drm: vmwgfx: fix common struct sg_table related issues

2020-06-18 Thread kernel test robot
Hi Marek, I love your patch! Yet something to improve: [auto build test ERROR on next-20200618] [also build test ERROR on v5.8-rc1] [cannot apply to linuxtv-media/master staging/staging-testing drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7 v5.7-rc7] [If your

Re: [PATCH 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a77961 support

2020-06-18 Thread Geert Uytterhoeven
On Thu, Jun 11, 2020 at 1:11 PM Yoshihiro Shimoda wrote: > Add support for r8a77961 (R-Car M3-W+). > > Signed-off-by: Yoshihiro Shimoda Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

Re: [PATCH v2 02/12] ocxl: Change type of pasid to unsigned int

2020-06-18 Thread Frederic Barrat
Le 13/06/2020 à 02:41, Fenghua Yu a écrit : PASID is defined as "int" although it's a 20-bit value and shouldn't be negative int. To be consistent with type defined in iommu, define PASID as "unsigned int". It looks like this patch was considered because of the use of 'pasid' in variable

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Andy Shevchenko
On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote: ... > (and likely call it "external" instead of "untrusted". Which is not okay. 'External' to what? 'untrusted' has been carefully chosen by the meaning of it. What external does

Re: [PATCH v3 01/13] iommu: Change type of pasid to unsigned int

2020-06-18 Thread Christoph Hellwig
On Wed, Jun 17, 2020 at 11:23:41AM -0700, Fenghua Yu wrote: > PASID is defined as a few different types in iommu including "int", > "u32", and "unsigned int". To be consistent and to match with ioasid's > type, define PASID and its variations (e.g. max PASID) as "unsigned int". Wouldn't u32 be a

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Wed, Jun 17, 2020 at 12:53:03PM -0700, Rajat Jain wrote: > Hi Greg, Christoph, > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote: > > > > On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote: > > > Need clarification. The flag "untrusted" is currently a part of > > > pci_dev

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-18 Thread Greg Kroah-Hartman
On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote: > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote: > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig > > wrote: > > ... > > > (and likely call it "external" instead of "untrusted". > > Which is not okay. 'External' to