On Tue, Apr 24, 2018 at 12:52:05AM +0100, Russell King - ARM Linux wrote:
> 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
> > indi
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 mm_struct
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 usa
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 request is sent to IOMMU to flush
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 usa
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 ++-
> 1 file change
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 address space.
>>
>> In cu
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 selec
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
+++ b/lib/swiotlb
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 insertions(+), 7 deletions(-)
diff --git a/
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 b/arch/arm/Kconfig
index aa1c18
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 +
arch/x86/Kconfig | 6 ++
lib/Kconfig
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| 4 +---
arc
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
---
arch/alph
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 ---
arch/arm64/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
ins
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 | 4 +---
arch/hexagon/Kconfig
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 23633c0fda4a..ded1703e7e64 100644
--- a/lib/iommu-helper.c
+++ b
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 => arch/sparc/include/asm}/iommu-common.h | 0
arch/sparc/include/asm/iommu_64.
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
tree
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
attemp
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 resto
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 initialisi
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 t
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 h
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
On Tue, Apr 10, 2018 at 02:20:41PM -0500, Bjorn Helgaas wrote:
> I assume you'll merge this via some non-PCI tree. Let me know if you
> need anything else from me.
I'll take it through the dma-mapping tree, so you should be fine.
___
iommu mailing list
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
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 t
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
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
> > +*/
> > + list_for_each_entry_s
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.
This should not have any functional change, but prepare for later patch.
Signed-off-by: Yisheng Xie
---
drivers/iommu/arm-smmu-v3.c | 11 +
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 nee
- 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 pro
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 faults (e.g. page request), inform
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, ¶m->fault_param->faults, list) {
I don't think you need th
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 = dev
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 driver
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
39 matches
Mail list logo
