Re: [PATCH v2 0/2] iommu: Remove iommu_sva_ops::mm_exit()

2020-05-27 Thread Joerg Roedel
Hi Jean-Philippe, On Wed, May 27, 2020 at 12:10:38PM +0200, Jean-Philippe Brucker wrote: > I was wondering if you could take these two patches for v5.8. The API > change is a precursor for the SVA support in SMMUv3, and the VT-d > implementation of the SVA API (queued for 5.8) doesn't implement >

Re: [PATCH 1/2] ia64: Hide the archdata.iommu field behind generic IOMMU_API

2020-05-27 Thread Joerg Roedel
On Mon, May 18, 2020 at 02:08:54PM +0200, Krzysztof Kozlowski wrote: > There is a generic, kernel wide configuration symbol for enabling the > IOMMU specific bits: CONFIG_IOMMU_API. Implementations (including > INTEL_IOMMU driver) select it so use it here as well. > > This makes the conditional

Re: [PATCH 2/2] x86: Hide the archdata.iommu field behind generic IOMMU_API

2020-05-27 Thread Borislav Petkov
On Mon, May 18, 2020 at 02:08:55PM +0200, Krzysztof Kozlowski wrote: > There is a generic, kernel wide configuration symbol for enabling the > IOMMU specific bits: CONFIG_IOMMU_API. Implementations (including > INTEL_IOMMU and AMD_IOMMU driver) select it so use it here as well. > > This makes

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Zhangfei Gao
On 2020/5/27 下午5:53, Arnd Bergmann wrote: On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman wrote: On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote: Some platform devices appear as PCI but are actually on the AMBA bus, Why would these devices not just show up on the AMBA bus

[PATCH 00/10] iommu/amd: Updates and Cleanups

2020-05-27 Thread Joerg Roedel
Hi, here is a collection of patches that clean up a few things in the AMD IOMMU driver. Foremost, it moves all related files of the driver into a separate subdirectory. But the patches also remove usage of dev->archdata.iommu and clean up dev_data handling and domain allocation. Patches are

[PATCH 10/10] iommu/amd: Remove redundant devid checks

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Checking the return value of get_device_id() in a code-path which has already done check_device() is not needed, as check_device() does the same check and bails out if it fails. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 13 ++--- 1 file changed, 2

[PATCH 01/10] iommu/amd: Move AMD IOMMU driver to a subdirectory

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel The driver consists of five C files and three header files by now. Move them to their own subdirectory to not clutter to iommu top-level directory with them. Signed-off-by: Joerg Roedel --- MAINTAINERS | 2 +- drivers/iommu/Makefile

[PATCH 03/10] iommu/amd: Let free_pagetable() not rely on domain->pt_root

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Use 'struct domain_pgtable' instead to free_pagetable(). This solves the problem that amd_iommu_domain_direct_map() needs to restore domain->pt_root after the device table has been updated just to make free_pagetable release the domain page-table. Signed-off-by: Joerg Roedel

[PATCH 06/10] iommu/amd: Consolidate domain allocation/freeing

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Merge the allocation code paths of DMA and UNMANAGED domains and remove code duplication. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 116 +- 1 file changed, 27 insertions(+), 89 deletions(-) diff --git

RE: [RFC] Use SMMU HTTU for DMA dirty page tracking

2020-05-27 Thread Zengtao (B)
> -Original Message- > From: zhengxiang (A) > Sent: Monday, May 25, 2020 7:34 PM > To: Jean-Philippe Brucker > Cc: linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu; > Will Deacon; Wanghaibin (D); Zengtao (B); m...@kernel.org; James Morse; > julien.thierry.k...@gmail.com;

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-27 Thread Nicolas Saenz Julienne
Hi Jim, one thing comes to mind, there is a small test suite in drivers/of/unittest.c (specifically of_unittest_pci_dma_ranges()) you could extend it to include your use cases. On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote: > The new field in struct device 'dma_pfn_offset_map' is used to

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

2020-05-27 Thread Will Deacon
Hi John, Bjorn, On Tue, May 26, 2020 at 01:34:45PM -0700, John Stultz wrote: > On Thu, May 14, 2020 at 12:34 PM wrote: > > > > On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote: > > > > Rob, Will, we're reaching the point where upstream has enough > > functionality that this is becoming a

[PATCH 08/10] iommu/amd: Merge private header files

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Merge amd_iommu_proto.h into amd_iommu.h. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/amd_iommu.h | 96 +++- drivers/iommu/amd/amd_iommu_proto.h | 97 - drivers/iommu/amd/debugfs.c | 5 +-

[PATCH 02/10] iommu/amd: Unexport get_dev_data()

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel This function is internal to the AMD IOMMU driver and only exported because the amd_iommu_v2 modules calls it. But the reason it is called from there could better be handled by amd_iommu_is_attach_deferred(). So unexport get_dev_data() and use amd_iommu_is_attach_deferred()

[PATCH 05/10] iommu/amd: Free page-table in protection_domain_free()

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Align release of the page-table with the place where it is allocated. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index

[PATCH 07/10] iommu/amd: Remove PD_DMA_OPS_MASK

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel This is covered by IOMMU_DOMAIN_DMA from the IOMMU core code already, so remove it. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 24 +++- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/drivers/iommu/amd/iommu.c

[PATCH 09/10] iommu/amd: Store dev_data as device iommu private data

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Do not use dev->archdata.iommu anymore and switch to using the private per-device pointer provided by the IOMMU core code. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 44 +++ 1 file changed, 22 insertions(+), 22

[PATCH 04/10] iommu/amd: Allocate page-table in protection_domain_init()

2020-05-27 Thread Joerg Roedel
From: Joerg Roedel Consolidate the allocation of the domain page-table in one place. Signed-off-by: Joerg Roedel --- drivers/iommu/amd/iommu.c | 48 ++- 1 file changed, 22 insertions(+), 26 deletions(-) diff --git a/drivers/iommu/amd/iommu.c

Re: [PATCH 0/2] drivers/iommu: Constify structs

2020-05-27 Thread Joerg Roedel
On Mon, May 25, 2020 at 11:49:56PM +0200, Rikard Falkeborn wrote: > Constify some structs with function pointers to allow the compiler to > put them in read-only memory. There is not dependency between the > patches. > > Rikard Falkeborn (2): > iommu/hyper-v: Constify hyperv_ir_domain_ops >

Re: [PATCH v2 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement

2020-05-27 Thread Joerg Roedel
On Wed, May 20, 2020 at 05:21:59PM +0200, Jean-Philippe Brucker wrote: > IOMMU drivers currently check themselves if a device is untrusted > (plugged into an external-facing port) before enabling ATS. Move the > check to drivers/pci. The only functional change should be to the AMD > IOMMU driver.

[PATCH v1 1/3] iommu/vt-d: Only clear real DMA device's context entries

2020-05-27 Thread Jon Derrick
Domain context mapping can encounter issues with sub-devices of a real DMA device. A sub-device cannot have a valid context entry due to it potentially aliasing another device's 16-bit ID. It's expected that sub-devices of the real DMA device uses the real DMA device's requester when context

[PATCH v1 3/3] iommu/vt-d: Remove real DMA lookup in find_domain

2020-05-27 Thread Jon Derrick
By removing the real DMA indirection in find_domain(), we can allow sub-devices of a real DMA device to have their own valid device_domain_info. The dmar lookup and context entry removal paths have been fixed to account for sub-devices. Fixes: 2b0140c69637 ("iommu/vt-d: Use pci_real_dma_dev() for

[PATCH v1 2/3] iommu/vt-d: Allocate domain info for real DMA sub-devices

2020-05-27 Thread Jon Derrick
Sub-devices of a real DMA device might exist on a separate segment than the real DMA device and its IOMMU. These devices should still have a valid device_domain_info, but the current dma alias model won't allocate info for the subdevice. This patch adds a segment member to struct

[PATCH v1 0/3] iommu/vt-d: real DMA sub-device info allocation

2020-05-27 Thread Jon Derrick
This set adds the support for real DMA sub-devices to have device_domain_info, leading to the correct domain type being used. This applies on Joerg's origin/next. This also applies against v5.6.12 and v5.7-rc7 with some API modifications, making it a stable candidate that fixes the issue reported

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-27 Thread Nicolas Saenz Julienne
Hi Jim, On Wed, 2020-05-27 at 11:43 -0400, Jim Quinlan wrote: > Hi Nicolas, > > On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne > wrote: > > Hi Jim, > > one thing comes to mind, there is a small test suite in > > drivers/of/unittest.c > > (specifically of_unittest_pci_dma_ranges()) you

Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets

2020-05-27 Thread Jim Quinlan via iommu
Hi Nicolas, On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne wrote: > > Hi Jim, > one thing comes to mind, there is a small test suite in drivers/of/unittest.c > (specifically of_unittest_pci_dma_ranges()) you could extend it to include > your > use cases. Sure, will check out. > > On

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Bjorn Helgaas
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote: > Some platform devices appear as PCI but are actually on the AMBA bus, > and they need fixup in drivers/pci/quirks.c handling iommu_fwnode. > Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode > is allocated, instead

Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address

2020-05-27 Thread Robin Murphy
On 2020-05-27 17:03, Srinath Mannam wrote: This patch gives the provision to change default value of MSI IOVA base to platform's suitable IOVA using module parameter. The present hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform. That in itself doesn't seem entirely

[RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address

2020-05-27 Thread Srinath Mannam via iommu
This patch gives the provision to change default value of MSI IOVA base to platform's suitable IOVA using module parameter. The present hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform. Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA

Re: [PATCH v2 0/2] iommu: Remove iommu_sva_ops::mm_exit()

2020-05-27 Thread Lu Baolu
Hi Jorge, On 2020/5/27 20:42, Joerg Roedel wrote: Hi Jean-Philippe, On Wed, May 27, 2020 at 12:10:38PM +0200, Jean-Philippe Brucker wrote: I was wondering if you could take these two patches for v5.8. The API change is a precursor for the SVA support in SMMUv3, and the VT-d implementation of

Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address

2020-05-27 Thread Srinath Mannam via iommu
On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote: > Thanks Robin for your quick response. > On 2020-05-27 17:03, Srinath Mannam wrote: > > This patch gives the provision to change default value of MSI IOVA base > > to platform's suitable IOVA using module parameter. The present > > hardcoded

Re: [PATCH v2 0/2] iommu: Remove iommu_sva_ops::mm_exit()

2020-05-27 Thread Lu Baolu
Sorry for the typo. On 2020/5/28 11:32, Lu Baolu wrote: Hi Jorge, ^ Joerg On 2020/5/27 20:42, Joerg Roedel wrote: Hi Jean-Philippe, On Wed, May 27, 2020 at 12:10:38PM +0200, Jean-Philippe Brucker wrote: I was wondering if you could take these two patches for v5.8. The API

RE: [RFC] Use SMMU HTTU for DMA dirty page tracking

2020-05-27 Thread Tian, Kevin
> From: Xiang Zheng > Sent: Wednesday, May 27, 2020 2:45 PM > > > On 2020/5/27 11:27, Tian, Kevin wrote: > >> From: Xiang Zheng > >> Sent: Monday, May 25, 2020 7:34 PM > >> > >> [+cc Kirti, Yan, Alex] > >> > >> On 2020/5/23 1:14, Jean-Philippe Brucker wrote: > >>> Hi, > >>> > >>> On Tue, May

Re: [PATCH v7 18/24] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

2020-05-27 Thread Jean-Philippe Brucker
On Wed, May 27, 2020 at 11:00:29AM +0800, Xiang Zheng wrote: > Hi Jean, > > This patch only enables HTTU bits in CDs. Is it also neccessary to enable > HTTU bits in STEs in this patch? Only if you need HTTU for stage-2 tables. This series is only about sharing stage-1 page tables, for which HTTU

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Greg Kroah-Hartman
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote: > Some platform devices appear as PCI but are actually on the AMBA bus, Why would these devices not just show up on the AMBA bus and use all of that logic instead of being a PCI device and having to go through odd fixes like this?

Re: [PATCH 2/2] iommu: calling pci_fixup_iommu in iommu_fwspec_init

2020-05-27 Thread Greg Kroah-Hartman
On Tue, May 26, 2020 at 07:49:09PM +0800, Zhangfei Gao wrote: > Calling pci_fixup_iommu in iommu_fwspec_init, which alloc > iommu_fwnode. Some platform devices appear as PCI but are > actually on the AMBA bus, and they need fixup in > drivers/pci/quirks.c handling iommu_fwnode. > So calling

Re: [PATCH 1/2] PCI: Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Greg Kroah-Hartman
On Tue, May 26, 2020 at 11:09:57PM +0800, Zhangfei Gao wrote: > Hi, Christoph > > On 2020/5/26 下午10:46, Christoph Hellwig wrote: > > On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote: > > > Some platform devices appear as PCI but are actually on the AMBA bus, > > > and they need fixup

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

2020-05-27 Thread Greg KH
On Tue, May 26, 2020 at 07:57:49PM +0200, Alexander Dahl wrote: > The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is > 4 294 967 296 or 0x1 which is no problem on 64 bit systems. The > patch does not change the later overall result of 0x10 for > MAX_DMA32_PFN. The

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

2020-05-27 Thread Laurentiu Tudor
On 5/26/2020 11:34 PM, John Stultz wrote: > On Thu, May 14, 2020 at 12:34 PM wrote: >> >> On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote: >> >> Rob, Will, we're reaching the point where upstream has enough >> functionality that this is becoming a critical issue for us. >> >> E.g. Lenovo

Re: [RFC] Use SMMU HTTU for DMA dirty page tracking

2020-05-27 Thread Jean-Philippe Brucker
On Wed, May 27, 2020 at 08:40:47AM +, Tian, Kevin wrote: > > From: Xiang Zheng > > Sent: Wednesday, May 27, 2020 2:45 PM > > > > > > On 2020/5/27 11:27, Tian, Kevin wrote: > > >> From: Xiang Zheng > > >> Sent: Monday, May 25, 2020 7:34 PM > > >> > > >> [+cc Kirti, Yan, Alex] > > >> > > >>

Re: [RFC] Use SMMU HTTU for DMA dirty page tracking

2020-05-27 Thread Xiang Zheng
On 2020/5/27 11:27, Tian, Kevin wrote: >> From: Xiang Zheng >> Sent: Monday, May 25, 2020 7:34 PM >> >> [+cc Kirti, Yan, Alex] >> >> On 2020/5/23 1:14, Jean-Philippe Brucker wrote: >>> Hi, >>> >>> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote: Hi all, Is there any

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

2020-05-27 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 still holding the iova's which can

Re: [PATCH v2 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement

2020-05-27 Thread Jean-Philippe Brucker
Hi Joerg, Bjorn, On Wed, May 20, 2020 at 05:21:59PM +0200, Jean-Philippe Brucker wrote: > IOMMU drivers currently check themselves if a device is untrusted > (plugged into an external-facing port) before enabling ATS. Move the > check to drivers/pci. The only functional change should be to the

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Arnd Bergmann
On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman wrote: > > On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote: > > Some platform devices appear as PCI but are actually on the AMBA bus, > > Why would these devices not just show up on the AMBA bus and use all of > that logic instead

Re: [PATCH v2 0/2] iommu: Remove iommu_sva_ops::mm_exit()

2020-05-27 Thread Jean-Philippe Brucker
Hi Joerg, I was wondering if you could take these two patches for v5.8. The API change is a precursor for the SVA support in SMMUv3, and the VT-d implementation of the SVA API (queued for 5.8) doesn't implement iommu_sva_ops. Thanks, Jean On Thu, Apr 23, 2020 at 02:53:27PM +0200, Jean-Philippe