Re: [PATCH 03/37] iommu/sva: Manage process address spaces

On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote: > /** > * iommu_sva_device_init() - Initialize Shared Virtual Addressing for a > device > * @dev: the device > @@ -129,7 +439,10 @@ EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown); > int iommu_sva_bind_device(struct device *dev, struct

Re: [PATCH 11/12] swiotlb: move the SWIOTLB config symbol to lib/Kconfig

On Mon, Apr 23, 2018 at 07:04:18PM +0200, Christoph Hellwig wrote: > This way we have one central definition of it, and user can select it as > needed. Note that we also add a second ARCH_HAS_SWIOTLB symbol to > indicate the architecture supports swiotlb at all, so that we can still > make the

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Fri, 20 Apr 2018 19:19:54 +0100 Jean-Philippe Brucker wrote: > Hi Jacob, > > On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: > [...] > > +/** > > + * enum iommu_inv_granularity - Generic invalidation granularity > > + * > > + * When an invalidation

Re: [PATCH 11/12] swiotlb: move the SWIOTLB config symbol to lib/Kconfig

On Mon, Apr 23, 2018 at 07:04:18PM +0200, Christoph Hellwig wrote: > This way we have one central definition of it, and user can select it as > needed. Note that we also add a second ARCH_HAS_SWIOTLB symbol to > indicate the architecture supports swiotlb at all, so that we can still > make the

Re: [PATCH 10/12] arm: don't build swiotlb by default

On Mon, Apr 23, 2018 at 07:04:17PM +0200, Christoph Hellwig wrote: > swiotlb is only used as a library of helper for xen-swiotlb if Xen support > is enabled on arm, so don't build it by default. > CCing Stefano > Signed-off-by: Christoph Hellwig > --- > arch/arm/Kconfig | 3 ++- >

Re: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA

On Mon, Apr 23, 2018 at 10:07 PM, Robin Murphy wrote: > On 19/04/18 18:12, Ganapatrao Kulkarni wrote: >> >> The performance drop is observed with long hours iperf testing using 40G >> cards. This is mainly due to long iterations in finding the free iova >> range in 32bit

[PATCH 11/12] swiotlb: move the SWIOTLB config symbol to lib/Kconfig

This way we have one central definition of it, and user can select it as needed. Note that we also add a second ARCH_HAS_SWIOTLB symbol to indicate the architecture supports swiotlb at all, so that we can still make the usage optional for a few architectures that want this feature to be user

[PATCH 12/12] swiotlb: remove the CONFIG_DMA_DIRECT_OPS ifdefs

swiotlb now selects the DMA_DIRECT_OPS config symbol, so this will always be true. Signed-off-by: Christoph Hellwig --- lib/swiotlb.c | 4 1 file changed, 4 deletions(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index fece57566d45..6954f7ad200a 100644 --- a/lib/swiotlb.c +++

[PATCH 09/12] PCI: remove CONFIG_PCI_BUS_ADDR_T_64BIT

This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so remove it. Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas --- drivers/pci/Kconfig | 4 drivers/pci/bus.c | 4 ++-- include/linux/pci.h | 2 +- 3 files changed, 3

[PATCH 07/12] arch: remove the ARCH_PHYS_ADDR_T_64BIT config symbol

Instead select the PHYS_ADDR_T_64BIT for 32-bit architectures that need a 64-bit phys_addr_t type directly. Signed-off-by: Christoph Hellwig --- arch/arc/Kconfig | 4 +--- arch/arm/kernel/setup.c| 2 +- arch/arm/mm/Kconfig

[PATCH 06/12] dma-mapping: move the NEED_DMA_MAP_STATE config symbol to lib/Kconfig

This way we have one central definition of it, and user can select it as needed. Note that we now also always select it when CONFIG_DMA_API_DEBUG is select, which fixes some incorrect checks in a few network drivers. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual

[PATCH 10/12] arm: don't build swiotlb by default

swiotlb is only used as a library of helper for xen-swiotlb if Xen support is enabled on arm, so don't build it by default. Signed-off-by: Christoph Hellwig --- arch/arm/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig

[PATCH 04/12] iommu-helper: move the IOMMU_HELPER config symbol to lib/

This way we have one central definition of it, and user can select it as needed. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual --- arch/powerpc/Kconfig | 4 +--- arch/s390/Kconfig| 5 ++--- arch/sparc/Kconfig | 5 +

[PATCH 03/12] iommu-helper: mark iommu_is_span_boundary as inline

This avoids selecting IOMMU_HELPER just for this function. And we only use it once or twice in normal builds so this often even is a size reduction. Signed-off-by: Christoph Hellwig --- arch/alpha/Kconfig | 3 --- arch/arm/Kconfig| 3 ---

[PATCH 08/12] arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig

Define this symbol if the architecture either uses 64-bit pointers or the PHYS_ADDR_T_64BIT is set. This covers 95% of the old arch magic. We only need an additional select for Xen on ARM (why anyway?), and we now always set ARCH_DMA_ADDR_T_64BIT on mips boards with 64-bit physical addressing

[PATCH 05/12] scatterlist: move the NEED_SG_DMA_LENGTH config symbol to lib/Kconfig

This way we have one central definition of it, and user can select it as needed. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual --- arch/alpha/Kconfig | 4 +--- arch/arm/Kconfig| 3 --- arch/arm64/Kconfig

[PATCH 02/12] iommu-helper: unexport iommu_area_alloc

This function is only used by built-in code. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual --- lib/iommu-helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c index

[PATCH 01/12] iommu-common: move to arch/sparc

This code is only used by sparc, and all new iommu drivers should use the drivers/iommu/ framework. Also remove the unused exports. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual --- {include/linux =>

centralize SWIOTLB config symbol and misc other cleanups V2

Hi all, this seris aims for a single defintion of the Kconfig symbol. To get there various cleanups, mostly about config symbols are included as well. Chances since V2 are a fixed s/Reviewed/Signed-Off/ for me, and a few reviewed-by tags. I'd like to start merging this into the dma-mapping

Re: [PATCH] iommu/iova: Update cached node pointer when current node fails to get any free IOVA

On 19/04/18 18:12, Ganapatrao Kulkarni wrote: The performance drop is observed with long hours iperf testing using 40G cards. This is mainly due to long iterations in finding the free iova range in 32bit address space. In current implementation for 64bit PCI devices, there is always first

Re: [RFC 2/2] iommu/arm-smmu-v3: Support software retention for pm_resume

On 23/04/18 12:45, Yisheng Xie wrote: When system suspend, hisilicon's smmu will do power gating for smmu, this time smmu's reg will be set to default value for not having hardware retention, which means need software do the retention instead. The patch is to use arm_smmu_device_reset() to

Re: [RFC 1/2] iommu/arm-smmu-v3: Remove bypass in arm_smmu_reset_device

On 23/04/18 12:45, Yisheng Xie wrote: Add a bypass parameter in arm_smmu_device to keep whether smmu device should pypass or not, so parameter bypass in arm_smmu_reset_device can be removed. Given that the GBPA configuration implied by the bypass argument here is only there to avoid

Re: [PATCH v4 13/22] iommu: introduce page response function

On 23/04/18 13:16, Jacob Pan wrote: > I shall drop these, only put in here to match your patch. i am looking > into converting vt-d svm prq to your queued fault patch. I think it will > give both functional and performance benefit. Thanks, I just rebased my patches onto this series and am hoping

Re: [PATCH v4 14/22] iommu: handle page response timeout

On Mon, Apr 16, 2018 at 10:49:03PM +0100, Jacob Pan wrote: > When IO page faults are reported outside IOMMU subsystem, the page > request handler may fail for various reasons. E.g. a guest received > page requests but did not have a chance to run for a long time. The > irresponsive behavior could

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

Can you resend your changes against Linux 4.17-rc2? There are a lot of conflicts as-is. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/2] dma-direct: Don't repeat allocation for no-op GFP_DMA

Thanks, applied to the dma-mapping tree for 4.17. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dma-coherent: Clarify dma_mmap_from_dev_coherent documentation

On Mon, Apr 09, 2018 at 06:59:14PM +0100, Robin Murphy wrote: > The use of "correctly mapped" here is misleading, since it can give the > wrong expectation in the case that the memory *should* have been mapped > from the per-device pool, but doing so failed for other reasons. Thanks, applied to

Re: [PATCH v2] base: dma-mapping: Postpone cpu addr translation on mmap()

Thanks, applied to the dma-mapping tree for 4.17. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 13/22] iommu: introduce page response function

On Mon, 23 Apr 2018 12:47:10 +0100 Jean-Philippe Brucker wrote: > On Mon, Apr 16, 2018 at 10:49:02PM +0100, Jacob Pan wrote: > [...] > > + /* > > +* Check if we have a matching page request pending to > > respond, > > +* otherwise return -EINVAL > > +

[RFC 2/2] iommu/arm-smmu-v3: Support software retention for pm_resume

When system suspend, hisilicon's smmu will do power gating for smmu, this time smmu's reg will be set to default value for not having hardware retention, which means need software do the retention instead. The patch is to use arm_smmu_device_reset() to restore the register of smmu. However, it

[RFC 0/2] iommu/arm-smmu-v3: Support software retention for pm_resume

- Backgroud: Hisilicon's implement of smmuv3 do not support hardware retention if system do power gating when system suspend, however for embed system, we do need to do power gating at trust zone for lower power comsume. So software retention is need. - Implement: From the process of smmu

Re: [PATCH v4 10/22] iommu: introduce device fault data

On Mon, 23 Apr 2018 11:11:41 +0100 Jean-Philippe Brucker wrote: > On Mon, Apr 16, 2018 at 10:48:59PM +0100, Jacob Pan wrote: > > +/** > > + * struct iommu_fault_event - Generic per device fault data > > + * > > + * - PCI and non-PCI devices > > + * - Recoverable

Re: [PATCH v4 13/22] iommu: introduce page response function

On Mon, Apr 16, 2018 at 10:49:02PM +0100, Jacob Pan wrote: [...] > + /* > + * Check if we have a matching page request pending to respond, > + * otherwise return -EINVAL > + */ > + list_for_each_entry_safe(evt, iter, >fault_param->faults, list) { I don't think you need the

Re: [PATCH v4 12/22] iommu: introduce device fault report API

On Mon, Apr 16, 2018 at 10:49:01PM +0100, Jacob Pan wrote: [...] > +int iommu_register_device_fault_handler(struct device *dev, > + iommu_dev_fault_handler_t handler, > + void *data) > +{ > + struct iommu_param *param =

Re: [PATCH v4 11/22] driver core: add per device iommu param

On Mon, Apr 16, 2018 at 02:49:00PM -0700, Jacob Pan wrote: > DMA faults can be detected by IOMMU at device level. Adding a pointer > to struct device allows IOMMU subsystem to report relevant faults > back to the device driver for further handling. > For direct assigned device (or user space

Re: [PATCH v4 10/22] iommu: introduce device fault data

On Mon, Apr 16, 2018 at 10:48:59PM +0100, Jacob Pan wrote: > +/** > + * struct iommu_fault_event - Generic per device fault data > + * > + * - PCI and non-PCI devices > + * - Recoverable faults (e.g. page request), information based on PCI ATS > + * and PASID spec. > + * - Un-recoverable faults of