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

2020-05-04 Thread Alex Williamson
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 Control Services (ACS) > Implementation of ACS in RCiEPs is permitted but not required. It is > explicitly permitted that, within

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

2020-05-04 Thread Ashok Raj
PCIe Spec recommends we can relax ACS requirement for RCIEP devices. PCIe 5.0 Specification. 6.12 Access Control Services (ACS) Implementation of ACS in RCiEPs is permitted but not required. It is explicitly permitted that, within a single Root Complex, some RCiEPs implement ACS and some do not.

Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line

2020-05-04 Thread Alexey Kardashevskiy
On 17/04/2020 17:58, Christoph Hellwig wrote: > On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote: >> And the fact they were exported leaves possibility that there is a >> driver somewhere relying on these symbols or distro kernel won't build >> because the symbol disappeared

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

2020-05-04 Thread Jacob Pan
On Mon, 4 May 2020 18:43:51 +0200 Jean-Philippe Brucker wrote: > On Thu, Apr 30, 2020 at 02:16:17PM -0700, Jacob Pan wrote: > > > +static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, > > > + struct mm_struct *mm, > > > +

Re: [PATCH 5.6 61/73] iommu/vt-d: Use right Kconfig option name

2020-05-04 Thread Joe Perches
On Mon, 2020-05-04 at 19:58 +0200, Greg Kroah-Hartman wrote: > From: Lu Baolu > > commit ba61c3da00f4a5bf8805aeca1ba5ac3c9bd82e96 upstream. > > The CONFIG_ prefix should be added in the code. > > Fixes: 046182525db61 ("iommu/vt-d: Add Kconfig option to enable/disable > scalable mode") >

[RFC PATCH] drivers: iommu: reset cached node if dma_mask is changed

2020-05-04 Thread Ajay Kumar
The current IOVA allocation code stores a cached copy of the first allocated IOVA address node, and all the subsequent allocations have no way to get past(higher than) the first allocated IOVA range. This causes issue when dma_mask for the master device is changed. Though the DMA window is

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

2020-05-04 Thread Jean-Philippe Brucker
On Thu, Apr 30, 2020 at 02:16:17PM -0700, Jacob Pan wrote: > > +static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, > > +struct mm_struct *mm, > > +unsigned long start, > > unsigned long end) +{ > > + /* TODO:

Re: [PATCH v6 19/25] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

2020-05-04 Thread Jean-Philippe Brucker
Hi, On Mon, May 04, 2020 at 07:54:03PM +0530, Prabhakar Kushwaha wrote: > Dear Jean, > > On Thu, Apr 30, 2020 at 8:11 PM Jean-Philippe Brucker > wrote: > > > > If the SMMU supports it and the kernel was built with HTTU support, enable > > is there any framework/config for HTTU which must be

Re: [PATCH v6 01/25] mm: Add a PASID field to mm_struct

2020-05-04 Thread Jean-Philippe Brucker
On Mon, May 04, 2020 at 09:52:44AM +0800, Xu Zaibo wrote: > > On 2020/4/30 22:34, Jean-Philippe Brucker wrote: > > Some devices can tag their DMA requests with a 20-bit Process Address > > Space ID (PASID), allowing them to access multiple address spaces. In > > combination with recoverable I/O

Re: [PATCH v6 05/25] iommu/iopf: Handle mm faults

2020-05-04 Thread Jean-Philippe Brucker
On Sun, May 03, 2020 at 01:54:36PM +0800, Lu Baolu wrote: > On 2020/4/30 22:34, Jean-Philippe Brucker wrote: > > When a recoverable page fault is handled by the fault workqueue, find the > > associated mm and call handle_mm_fault. > > > > Signed-off-by: Jean-Philippe Brucker > > --- > > v5->v6:

Re: [PATCH v6 04/25] iommu: Add a page fault handler

2020-05-04 Thread Jean-Philippe Brucker
On Sun, May 03, 2020 at 01:49:01PM +0800, Lu Baolu wrote: > > +static void iopf_handle_group(struct work_struct *work) > > +{ > > + struct iopf_group *group; > > + struct iopf_fault *iopf, *next; > > + enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS; > > + > > + group =

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

2020-05-04 Thread Jean-Philippe Brucker
On Fri, May 01, 2020 at 09:55:13AM -0300, Jason Gunthorpe wrote: > On Fri, May 01, 2020 at 05:15:52AM -0700, Christoph Hellwig wrote: > > > @@ -432,6 +432,7 @@ config ARM_SMMU_V3 > > > tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > > > depends on ARM64 > > > select IOMMU_API > >

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

2020-05-04 Thread Jean-Philippe Brucker
On Fri, May 01, 2020 at 05:15:52AM -0700, Christoph Hellwig wrote: > > @@ -432,6 +432,7 @@ config ARM_SMMU_V3 > > tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > > depends on ARM64 > > select IOMMU_API > > + select IOMMU_SVA > > select IOMMU_IO_PGTABLE_LPAE > >

Re: [PATCH v6 02/25] iommu/ioasid: Add ioasid references

2020-05-04 Thread Jacob Pan
On Mon, 4 May 2020 16:25:48 +0200 Jean-Philippe Brucker wrote: > On Thu, Apr 30, 2020 at 11:39:31AM -0700, Jacob Pan wrote: > > > +/** > > > + * ioasid_get - obtain a reference to the IOASID > > > + */ > > > +void ioasid_get(ioasid_t ioasid) > > why void? what if the ioasid is not valid. >

Re: [PATCH v6 02/25] iommu/ioasid: Add ioasid references

2020-05-04 Thread Jacob Pan
On Mon, 4 May 2020 16:39:32 +0200 Jean-Philippe Brucker wrote: > On Thu, Apr 30, 2020 at 01:48:42PM -0700, Jacob Pan wrote: > > On Thu, 30 Apr 2020 11:39:31 -0700 > > Jacob Pan wrote: > > > > > > -void ioasid_free(ioasid_t ioasid) > > > > +bool ioasid_free(ioasid_t ioasid) > > > > { > >

Re: [PATCH v6 00/25] iommu: Shared Virtual Addressing for SMMUv3

2020-05-04 Thread Jean-Philippe Brucker
On Thu, Apr 30, 2020 at 02:18:16PM -0700, Jacob Pan wrote: > On Thu, 30 Apr 2020 16:33:59 +0200 > Jean-Philippe Brucker wrote: > > > Shared Virtual Addressing (SVA) allows to share process page tables > > with devices using the IOMMU, PASIDs and I/O page faults. Add SVA > > support to the Arm

Re: [PATCH v6 02/25] iommu/ioasid: Add ioasid references

2020-05-04 Thread Jean-Philippe Brucker
On Thu, Apr 30, 2020 at 01:48:42PM -0700, Jacob Pan wrote: > On Thu, 30 Apr 2020 11:39:31 -0700 > Jacob Pan wrote: > > > > -void ioasid_free(ioasid_t ioasid) > > > +bool ioasid_free(ioasid_t ioasid) > > > { > Sorry I missed this in the last reply. > > I think free needs to be unconditional

Re: [PATCH v6 11/25] iommu/arm-smmu-v3: Share process page tables

2020-05-04 Thread Suzuki K Poulose
On 05/04/2020 03:11 PM, Jean-Philippe Brucker wrote: On Thu, Apr 30, 2020 at 04:39:53PM +0100, Suzuki K Poulose wrote: On 04/30/2020 03:34 PM, Jean-Philippe Brucker wrote: With Shared Virtual Addressing (SVA), we need to mirror CPU TTBR, TCR, MAIR and ASIDs in SMMU contexts. Each SMMU has a

Re: [PATCH v6 02/25] iommu/ioasid: Add ioasid references

2020-05-04 Thread Jean-Philippe Brucker
On Thu, Apr 30, 2020 at 11:39:31AM -0700, Jacob Pan wrote: > > +/** > > + * ioasid_get - obtain a reference to the IOASID > > + */ > > +void ioasid_get(ioasid_t ioasid) > why void? what if the ioasid is not valid. My intended use was for the caller to get an additional reference when they're

Re: [PATCH v6 19/25] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

2020-05-04 Thread Prabhakar Kushwaha
Dear Jean, On Thu, Apr 30, 2020 at 8:11 PM Jean-Philippe Brucker wrote: > > If the SMMU supports it and the kernel was built with HTTU support, enable is there any framework/config for HTTU which must be enabled to use this patch? > We can enable HTTU even if CPUs don't support it, because

Re: [PATCH v6 11/25] iommu/arm-smmu-v3: Share process page tables

2020-05-04 Thread Jean-Philippe Brucker
On Thu, Apr 30, 2020 at 04:39:53PM +0100, Suzuki K Poulose wrote: > On 04/30/2020 03:34 PM, Jean-Philippe Brucker wrote: > > 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

Re: [PATCH v2 09/21] drm: panfrost: fix sg_table nents vs. orig_nents misuse

2020-05-04 Thread Steven Price
On 04/05/2020 13:53, 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 with the original number of

Re: [PATCH v2 00/21] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-04 Thread Christoph Hellwig
On Mon, May 04, 2020 at 03:05:30PM +0200, Marek Szyprowski wrote: > Hi Christoph, > > On 04.05.2020 14:52, Christoph Hellwig wrote: > > On Mon, May 04, 2020 at 02:50:17PM +0200, Marek Szyprowski wrote: > >> v2: > >> - dropped most of the changes to drm/i915 > >> - added fixes for rcar-du, xen,

Re: [PATCH v2 00/21] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-04 Thread Marek Szyprowski
Hi Christoph, On 04.05.2020 14:52, Christoph Hellwig wrote: > On Mon, May 04, 2020 at 02:50:17PM +0200, Marek Szyprowski wrote: >> v2: >> - dropped most of the changes to drm/i915 >> - added fixes for rcar-du, xen, media and ion >> - fixed a few issues pointed by kbuild test robot >> - added wide

[PATCH v2 07/21] drm: lima: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 17/21] drm: rcar-du: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 13/21] drm: virtio: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 20/21] media: pci: fix common ALSA DMA-mapping related code

2020-05-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 1/5] iommu/amd: Fix race in increase_address_space()/fetch_pte()

2020-05-04 Thread Joerg Roedel
From: Joerg Roedel The 'pt_root' and 'mode' struct members of 'struct protection_domain' need to be get/set atomically, otherwise the page-table of the domain can get corrupted. Merge the fields into one atomic64_t struct member which can be get/set atomically. Fixes: 92d420ec028d ("iommu/amd:

[PATCH v2 02/21] drm: amdgpu: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 12/21] drm: tegra: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 18/21] xen: gntdev: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 05/21] drm: exynos: fix sg_table nents vs. orig_nents misuse

2020-05-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 4/5] iommu/amd: Update Device Table in increase_address_space()

2020-05-04 Thread Joerg Roedel
From: Joerg Roedel The Device Table needs to be updated before the new page-table root can be published in domain->pt_root. Otherwise a concurrent call to fetch_pte might fetch a PTE which is not reachable through the Device Table Entry. Fixes: 92d420ec028d ("iommu/amd: Relax locking in dma_ops

[PATCH 5/5] iommu/amd: Do not flush Device Table in iommu_map_page()

2020-05-04 Thread Joerg Roedel
From: Joerg Roedel The flush of the Device Table Entries for the domain has already happened in increase_address_space(), if necessary. Do no flush them again in iommu_map_page(). Tested-by: Qian Cai Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 27 ---

[PATCH v2 19/21] dmabuf: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 03/21] drm: armada: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 09/21] drm: panfrost: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 15/21] drm: xen: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 06/21] drm: i915: fix sg_table nents vs. orig_nents misuse for dmabuf objects

2020-05-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 v2 21/21] staging: ion: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 01/21] drm: core: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 04/21] drm: etnaviv: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 16/21] drm: host1x: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 08/21] drm: msm: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 10/21] drm: radeon: fix sg_table nents vs. orig_nents misuse

2020-05-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 0/5] iommu/amd: Fix race conditions around increase_address_space()

2020-05-04 Thread Joerg Roedel
Hi, Qian reported more race conditions around the dma-mapping code path in the AMD IOMMU driver. The race condtions are between increas_address_space() and fetch_pte(), there were two of them: 1) the 'pt_root' and 'mode' fields of 'struct protection_domain' relate to each

[PATCH v2 14/21] drm: vmwgfx: fix sg_table nents vs. orig_nents misuse

2020-05-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 v2 11/21] drm: rockchip: fix sg_table nents vs. orig_nents misuse

2020-05-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 2/5] iommu/amd: Do not loop forever when trying to increase address space

2020-05-04 Thread Joerg Roedel
From: Joerg Roedel When increase_address_space() fails to allocate memory, alloc_pte() will call it again until it succeeds. Do not loop forever while trying to increase the address space and just return an error instead. Tested-by: Qian Cai Signed-off-by: Joerg Roedel ---

[PATCH 3/5] iommu/amd: Call domain_flush_complete() in update_domain()

2020-05-04 Thread Joerg Roedel
From: Joerg Roedel The update_domain() function is expected to also inform the hardware about domain changes. This needs a COMPLETION_WAIT command to be sent to all IOMMUs which use the domain. Tested-by: Qian Cai Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 1 + 1 file

Re: [PATCH v2 00/21] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-04 Thread Christoph Hellwig
On Mon, May 04, 2020 at 02:50:17PM +0200, Marek Szyprowski wrote: > v2: > - dropped most of the changes to drm/i915 > - added fixes for rcar-du, xen, media and ion > - fixed a few issues pointed by kbuild test robot > - added wide cc: list for each patch Didn't you plan to add dma_map_sgbuf and

[PATCH v2 00/21] DRM: fix struct sg_table nents vs. orig_nents misuse

2020-05-04 Thread Marek Szyprowski
}_sgtable() wrappers, which will use a proper sg_table entries and call respective DMA-mapping functions. I hope this will help to avoid issue like this in the future. Patches are based on top of Linux next-20200504. Best regards, Marek Szyprowski References: [1] https://lkml.org/lkml/2020/3/27/555