Re: [PATCH v6 03/10] iommu/mediatek: Use a u32 flags to describe different HW features

2020-07-03 Thread Yingjoe Chen
On Fri, 2020-07-03 at 12:41 +0800, Chao Hao wrote: > Given the fact that we are adding more and more plat_data bool values, > it would make sense to use a u32 flags register and add the appropriate > macro definitions to set and check for a flag present. > No functional change. > > Cc: Yong Wu >

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

2020-07-03 Thread Qian Cai
On Tue, Jun 30, 2020 at 08:40:28PM -0400, Qian Cai wrote: > On Wed, Apr 29, 2020 at 03:36:38PM +0200, Joerg Roedel wrote: > > Hi, > > > > here is the third version of this patch-set. Older versions can be found > > here: > > > > v1:

[PATCH] iommu: fix use-after-free in iommu_release_device

2020-07-03 Thread Qian Cai
In pci_disable_sriov(), i.e., # echo 0 > /sys/class/net/enp11s0f1np1/device/sriov_numvfs iommu_release_device iommu_group_remove_device arm_smmu_domain_free kfree(smmu_domain) Later, iommu_release_device arm_smmu_release_device arm_smmu_detach_dev

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

2020-07-03 Thread Sai Prakash Ranjan
On 2020-07-03 21:34, Rob Clark wrote: On Fri, Jul 3, 2020 at 7:53 AM Sai Prakash Ranjan wrote: Hi Will, On 2020-07-03 19:07, Will Deacon wrote: > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: >> diff --git a/drivers/gpu/drm/msm/msm_iommu.c >>

Re: [PATCH] iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag

2020-07-03 Thread Sai Prakash Ranjan
On 2020-07-03 21:55, Will Deacon wrote: The IOMMU_SYS_CACHE_ONLY flag was never exposed via the DMA API and has no in-tree users. Remove it. Cc: Robin Murphy Cc: "Isaac J. Manjarres" Cc: Joerg Roedel Cc: Christoph Hellwig Cc: Sai Prakash Ranjan Cc: Rob Clark Signed-off-by: Will Deacon

[PATCH] iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag

2020-07-03 Thread Will Deacon
The IOMMU_SYS_CACHE_ONLY flag was never exposed via the DMA API and has no in-tree users. Remove it. Cc: Robin Murphy Cc: "Isaac J. Manjarres" Cc: Joerg Roedel Cc: Christoph Hellwig Cc: Sai Prakash Ranjan Cc: Rob Clark Signed-off-by: Will Deacon --- As discussed in [1], sounds like this

Re: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs

2020-07-03 Thread Will Deacon
On Sat, May 30, 2020 at 09:15:05PM +1200, Barry Song wrote: > As tests show the latency of dma_unmap can increase dramatically while > calling them cross NUMA nodes, especially cross CPU packages, eg. > 300ns vs 800ns while waiting for the completion of CMD_SYNC in an > empty command queue. The

Re: [PATCH] iommu/arm-smmu-v3: allocate the memory of queues in local numa node

2020-07-03 Thread Will Deacon
On Mon, Jun 01, 2020 at 11:31:41PM +1200, Barry Song wrote: > dmam_alloc_coherent() will usually allocate memory from the default CMA. For > a common arm64 defconfig without reserved memory in device tree, there is only > one CMA close to address 0. > dma_alloc_contiguous() will allocate memory

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

2020-07-03 Thread Rob Clark
On Fri, Jul 3, 2020 at 7:53 AM Sai Prakash Ranjan wrote: > > Hi Will, > > On 2020-07-03 19:07, Will Deacon wrote: > > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > >> diff --git a/drivers/gpu/drm/msm/msm_iommu.c > >> b/drivers/gpu/drm/msm/msm_iommu.c > >> index

[PATCH 1/2] iommu: Tidy up Kconfig for SoC IOMMUs

2020-07-03 Thread Robin Murphy
Wacky COMPILE_TEST dependencies based on who used to define dev_archdata.iommu can go. Dependencies on ARM or ARM64 already implied by the ARCH_* platform selection can go. The entire IOMMU_SUPPORT menu already depends on MMU, so those can go. IOMMU_DMA is for the architecture's DMA API

[PATCH 2/2] iommu/renesas: Expand COMPILE_TEST coverage

2020-07-03 Thread Robin Murphy
This driver shouldn't need anything architecture-specific (that isn't under CONFIG_ARM protection already), and has already been accessible from certain x86 configurations by virtue of the previously-cleaned-up "ARM || IOMMU_DMA" dependency. Allow COMPILE_TEST for all architectures.

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

2020-07-03 Thread Will Deacon
On Fri, Jul 03, 2020 at 08:23:07PM +0530, Sai Prakash Ranjan wrote: > On 2020-07-03 19:07, Will Deacon wrote: > > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > > > diff --git a/drivers/gpu/drm/msm/msm_iommu.c > > > b/drivers/gpu/drm/msm/msm_iommu.c > > > index

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

2020-07-03 Thread Sai Prakash Ranjan
Hi Will, On 2020-07-03 19:07, Will Deacon wrote: On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index f455c597f76d..bd1d58229cc2 100644 --- a/drivers/gpu/drm/msm/msm_iommu.c +++

[PATCH 1/2] iommu/iova: Retry from last rb tree node if iova search fails

2020-07-03 Thread vjitta
From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH 2/2] iommu/iova: Free global iova rcache on iova alloc failure

2020-07-03 Thread vjitta
From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

2020-07-03 Thread Will Deacon
On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c > index f455c597f76d..bd1d58229cc2 100644 > --- a/drivers/gpu/drm/msm/msm_iommu.c > +++ b/drivers/gpu/drm/msm/msm_iommu.c > @@ -218,6 +218,9 @@

RE: [PATCH v3 03/14] vfio/type1: Report iommu nesting info to userspace

2020-07-03 Thread Liu, Yi L
Hi Alex, > From: Liu, Yi L > Sent: Friday, July 3, 2020 2:06 PM [...] > > > +#define VFIO_IOMMU_TYPE1_INFO_CAP_NESTING 3 > > > + > > > +struct vfio_iommu_type1_info_cap_nesting { > > > + struct vfio_info_cap_header header; > > > + __u32 flags; > > > > I think there's an alignment issue here

Re: [RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-07-03 Thread Vinod Koul
On 03-07-20, 13:23, Will Deacon wrote: > On Tue, Jun 16, 2020 at 01:52:32PM -0700, John Stultz wrote: > > On Tue, Jun 16, 2020 at 12:55 AM Marc Zyngier wrote: > > > On 2020-06-16 07:13, John Stultz wrote: > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > > index

Re: [RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-07-03 Thread Will Deacon
On Tue, Jun 16, 2020 at 01:52:32PM -0700, John Stultz wrote: > On Tue, Jun 16, 2020 at 12:55 AM Marc Zyngier wrote: > > On 2020-06-16 07:13, John Stultz wrote: > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > index b510f67dfa49..714893535dd2 100644 > > > ---

Re: [PATCH v3 2/4] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743

2020-07-03 Thread Tomasz Nowicki
On 03.07.2020 11:03, Robin Murphy wrote: On 2020-07-02 21:16, Tomasz Nowicki wrote: From: Hanna Hawa Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to ARM SMMUv2 registers. Provide implementation relevant hooks: - split the writeq/readq to two accesses of writel/readl.

Re: [PATCH v3 02/14] iommu: Report domain nesting info

2020-07-03 Thread Stefan Hajnoczi
On Tue, Jun 30, 2020 at 02:00:49AM +, Tian, Kevin wrote: > > From: Liu, Yi L > > Sent: Monday, June 29, 2020 8:23 PM > > > > Hi Stefan, > > > > > From: Stefan Hajnoczi > > > Sent: Monday, June 29, 2020 5:25 PM > > > > > > On Wed, Jun 24, 2020 at 01:55:15AM -0700, Liu Yi L wrote: > > > >

Re: [PATCH v3 4/4] arm64: dts: marvell: add SMMU support

2020-07-03 Thread Tomasz Nowicki
On 03.07.2020 11:16, Robin Murphy wrote: On 2020-07-02 21:16, Tomasz Nowicki wrote: From: Marcin Wojtas Add IOMMU node for Marvell AP806 based SoCs together with platform and PCI device Stream ID mapping. Signed-off-by: Marcin Wojtas Signed-off-by: Tomasz Nowicki ---  

Re: [PATCH v3 3/4] dt-bindings: arm-smmu: add compatible string for Marvell Armada-AP806 SMMU-500

2020-07-03 Thread Tomasz Nowicki
On 03.07.2020 11:05, Robin Murphy wrote: On 2020-07-02 21:16, Tomasz Nowicki wrote: Add specific compatible string for Marvell usage due to errata of accessing 64bits registers of ARM SMMU, in AP806. AP806 SoC uses the generic ARM-MMU500, and there's no specific implementation of Marvell, this

Re: [PATCH v3 1/4] iommu/arm-smmu: Add SMMU ID2 register fixup hook

2020-07-03 Thread Tomasz Nowicki
On 03.07.2020 10:24, Robin Murphy wrote: On 2020-07-02 21:16, Tomasz Nowicki wrote: We already have 'cfg_probe' hook which meant to override and apply workarounds while probing ID registers. However, 'cfg_probe' is called at the very end and therefore for some cases fixing up things becomes

Re: [PATCH v3 4/4] arm64: dts: marvell: add SMMU support

2020-07-03 Thread Robin Murphy
On 2020-07-02 21:16, Tomasz Nowicki wrote: From: Marcin Wojtas Add IOMMU node for Marvell AP806 based SoCs together with platform and PCI device Stream ID mapping. Signed-off-by: Marcin Wojtas Signed-off-by: Tomasz Nowicki --- arch/arm64/boot/dts/marvell/armada-8040.dtsi | 36

Re: [PATCH v3 3/4] dt-bindings: arm-smmu: add compatible string for Marvell Armada-AP806 SMMU-500

2020-07-03 Thread Robin Murphy
On 2020-07-02 21:16, Tomasz Nowicki wrote: Add specific compatible string for Marvell usage due to errata of accessing 64bits registers of ARM SMMU, in AP806. AP806 SoC uses the generic ARM-MMU500, and there's no specific implementation of Marvell, this compatible is used for errata only.

Re: [PATCH v3 2/4] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum #582743

2020-07-03 Thread Robin Murphy
On 2020-07-02 21:16, Tomasz Nowicki wrote: From: Hanna Hawa Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to ARM SMMUv2 registers. Provide implementation relevant hooks: - split the writeq/readq to two accesses of writel/readl. - mask the MMU_IDR2.PTFSv8 fields to not

Re: [PATCH v3 1/4] iommu/arm-smmu: Add SMMU ID2 register fixup hook

2020-07-03 Thread Robin Murphy
On 2020-07-02 21:16, Tomasz Nowicki wrote: We already have 'cfg_probe' hook which meant to override and apply workarounds while probing ID registers. However, 'cfg_probe' is called at the very end and therefore for some cases fixing up things becomes complex or requires exporting of SMMU driver

Re: [PATCH v5 01/12] iommu: Change type of pasid to u32

2020-07-03 Thread Felix Kuehling
Am 2020-07-02 um 3:10 p.m. schrieb Fenghua Yu: > Hi, Felix, Thomas, Joerg and maintainers, > > On Tue, Jun 30, 2020 at 10:12:38PM -0400, Felix Kuehling wrote: >> Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu: >> You didn't change the return types of amdgpu_pasid_alloc and >> kfd_pasid_alloc.

RE: [PATCH v3 09/14] vfio/type1: Support binding guest page tables to PASID

2020-07-03 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Friday, July 3, 2020 5:20 AM > > On Wed, 24 Jun 2020 01:55:22 -0700 > Liu Yi L wrote: > > > Nesting translation allows two-levels/stages page tables, with 1st > > level for guest translations (e.g. GVA->GPA), 2nd level for host > > translations (e.g.

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

2020-07-03 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Friday, July 3, 2020 5:19 AM > > On Wed, 24 Jun 2020 01:55:19 -0700 > Liu Yi L wrote: > > > This patch allows user space to request PASID allocation/free, e.g. > > when serving the request from the guest. > > > > PASIDs that are not freed by userspace

RE: [PATCH v3 04/14] vfio: Add PASID allocation/free support

2020-07-03 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson > Sent: Friday, July 3, 2020 5:17 AM > > On Wed, 24 Jun 2020 01:55:17 -0700 > Liu Yi L wrote: > > > Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing > > multiple process virtual address spaces with the device for simplified > >

RE: [PATCH v3 03/14] vfio/type1: Report iommu nesting info to userspace

2020-07-03 Thread Liu, Yi L
Hi Alex, > From: Alex Williamson < alex.william...@redhat.com > > Sent: Friday, July 3, 2020 2:39 AM > > On Wed, 24 Jun 2020 01:55:16 -0700 > Liu Yi L wrote: > > > This patch exports iommu nesting capability info to user space through > > VFIO. User space is expected to check this info for