[PATCH] iommu/dma: limit the IOVA allocated to dma-ranges region

2017-08-31 Thread Krishna Reddy
Limit the IOVA allocated to dma-ranges specified for the device. This is necessary to ensure that IOVA allocated is addressable by device. Signed-off-by: Krishna Reddy --- drivers/iommu/dma-iommu.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 07/13] iommu/amd: update to new mmu_notifier semantic

2017-08-31 Thread jglisse
From: Jérôme Glisse Call to mmu_notifier_invalidate_page() are replaced by call to mmu_notifier_invalidate_range() and thus call are bracketed by call to mmu_notifier_invalidate_range_start()/end() Remove now useless invalidate_page callback. Signed-off-by: Jérôme Glisse

[PATCH 08/13] iommu/intel: update to new mmu_notifier semantic

2017-08-31 Thread jglisse
From: Jérôme Glisse Call to mmu_notifier_invalidate_page() are replaced by call to mmu_notifier_invalidate_range() and thus call are bracketed by call to mmu_notifier_invalidate_range_start()/end() Remove now useless invalidate_page callback. Signed-off-by: Jérôme Glisse

[PATCH 00/13] mmu_notifier kill invalidate_page callback v2

2017-08-31 Thread jglisse
From: Jérôme Glisse (Sorry for so many list cross-posting and big cc) Changes since v1: - remove more dead code in kvm (no testing impact) - more accurate end address computation (patch 2) in page_mkclean_one and try_to_unmap_one - added tested-by/reviewed-by

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

2017-08-31 Thread Nadav Amit
Andrea Arcangeli wrote: > On Wed, Aug 30, 2017 at 08:47:19PM -0400, Jerome Glisse wrote: >> On Wed, Aug 30, 2017 at 04:25:54PM -0700, Nadav Amit wrote: >>> For both CoW and KSM, the correctness is maintained by calling >>> ptep_clear_flush_notify(). If you defer the

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

2017-08-31 Thread Andrea Arcangeli
On Wed, Aug 30, 2017 at 08:47:19PM -0400, Jerome Glisse wrote: > On Wed, Aug 30, 2017 at 04:25:54PM -0700, Nadav Amit wrote: > > For both CoW and KSM, the correctness is maintained by calling > > ptep_clear_flush_notify(). If you defer the secondary MMU invalidation > > (i.e., replacing

Re: [PATCH 04/12] x86: make dma_cache_sync a no-op

2017-08-31 Thread Thomas Gleixner
On Sun, 27 Aug 2017, Christoph Hellwig wrote: > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > make any sense to do any work in dma_cache_sync given that it must be a > no-op when dma_alloc_attrs returns coherent memory. > > Signed-off-by: Christoph Hellwig

[RFT] iommu/arm-smmu-v3: Use burst-polling for sync completion

2017-08-31 Thread Robin Murphy
While CMD_SYNC is unlikely to complete immediately such that we never go round the polling loop, with a lightly-loaded queue it may still do so long before the delay period is up. If we have no better completion notifier, use similar logic as we have for SMMUv2 to spin a number of times before

[PATCH v2 4/4] iommu/arm-smmu-v3: Poll for CMD_SYNC outside cmdq lock

2017-08-31 Thread Robin Murphy
Even without the MSI trick, we can still do a lot better than hogging the entire queue while it drains. All we actually need to do for the necessary guarantee of completion is wait for our particular command to have been consumed, and as long as we keep track of where it is there is no need to

[PATCH v2 3/4] iommu/arm-smmu-v3: Use CMD_SYNC completion MSI

2017-08-31 Thread Robin Murphy
As an IRQ, the CMD_SYNC interrupt is not particularly useful, not least because we often need to wait for sync completion within someone else's IRQ handler anyway. However, when the SMMU is both coherent and supports MSIs, we can have a lot more fun by not using it as an interrupt at all.

[PATCH v2 2/4] iommu/arm-smmu-v3: Forget about cmdq-sync interrupt

2017-08-31 Thread Robin Murphy
The cmdq-sync interrupt is never going to be particularly useful, since for stage 1 DMA at least we'll often need to wait for sync completion within someone else's IRQ handler, thus have to implement polling anyway. Beyond that, the overhead of taking an interrupt, then still having to grovel

[PATCH v2 1/4] iommu/arm-smmu-v3: Specialise CMD_SYNC handling

2017-08-31 Thread Robin Murphy
CMD_SYNC already has a bit of special treatment here and there, but as we're about to extend it with more functionality for completing outside the CMDQ lock, things are going to get rather messy if we keep trying to cram everything into a single generic command interface. Instead, let's break out

[PATCH v2 0/4] SMMUv3 CMD_SYNC optimisation

2017-08-31 Thread Robin Murphy
Hi all, Since Nate reported a reasonable performance boost from the out-of-line MSI polling in v1 [1], I've now implemented the equivalent for cons polling as well - that has been boot-tested on D05 with some trivial I/O and at least doesn't seem to lock up or explode. There's also a little

[PATCH 0/2] Dual MMU support for TI DRA7xx DSPs

2017-08-31 Thread Suman Anna via iommu
Hi Joerg, The following two patches enhance the OMAP IOMMU driver to support mirror-programming of two MMUs present within the DSP subsystems specifically on TI DRA7xx/AM57xx family of SOCs. The TI OMAP DSP subsystems traditionally always has a DSP core and an internal EDMA block behind a single

[PATCH 2/2] iommu/omap: Add support to program multiple iommus

2017-08-31 Thread Suman Anna via iommu
A client user instantiates and attaches to an iommu_domain to program the OMAP IOMMU associated with the domain. The iommus programmed by a client user are bound with the iommu_domain through the user's device archdata. The OMAP IOMMU driver currently supports only one IOMMU per IOMMU domain per

[PATCH 1/2] iommu/omap: Change the attach detection logic

2017-08-31 Thread Suman Anna via iommu
The OMAP IOMMU driver allows only a single device (eg: a rproc device) to be attached per domain. The current attach detection logic relies on a check for an attached iommu for the respective client device. Change this logic to use the client device pointer instead in preparation for supporting

Re: [PATCH v2] iommu/vt-d: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Woodhouse, David via iommu
On Thu, 2017-08-31 at 10:58 +0200, Filippo Sironi wrote: > Previously, we were invalidating context cache and IOTLB globally when > clearing one context entry.  This is a tad too aggressive. > Invalidate the context cache and IOTLB for the interested device only. > > Signed-off-by: Filippo Sironi

Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device

2017-08-31 Thread Jörg Rödel
Yes, I was running some tests against the new tree which didn't finish yesterday. Today I am traveling, but will be back im the evening and then I push the tree out. Regards, Joerg Sent from a Galaxy Class Phone Ursprüngliche Nachricht Von: Jon Hunter

Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device

2017-08-31 Thread Jon Hunter
Hi Joerg, On 30/08/17 16:30, Joerg Roedel wrote: > Hi Jon, > > On Wed, Aug 30, 2017 at 03:22:05PM +0100, Jon Hunter wrote: >> Yes I can confirm that this fixes the crash. I assume that you will fix >> the error path for bus_set_iommu() above as I believe now it needs to >> call

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

2017-08-31 Thread Leizhen (ThunderTown)
On 2017/8/4 3:41, Nate Watterson wrote: > Hi Robin, > > On 7/31/2017 7:42 AM, Robin Murphy wrote: >> Hi Nate, >> >> On 29/07/17 04:57, Nate Watterson wrote: >>> Hi Robin, >>> I am seeing a crash when performing very basic testing on this series >>> with a Mellanox CX4 NIC. I dug into the crash

[PATCH v2] iommu/vt-d: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Filippo Sironi via iommu
Previously, we were invalidating context cache and IOTLB globally when clearing one context entry. This is a tad too aggressive. Invalidate the context cache and IOTLB for the interested device only. Signed-off-by: Filippo Sironi Cc: David Woodhouse Cc:

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Sironi, Filippo via iommu
Hi Jacob, > On 30. Aug 2017, at 17:50, Jacob Pan wrote: > > On Mon, 28 Aug 2017 16:16:29 +0200 > Filippo Sironi via iommu wrote: > >> Previously, we were invalidating context cache and IOTLB globally when >> clearing one context

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

2017-08-31 Thread Sironi, Filippo via iommu
Hi Joerg, > On 30. Aug 2017, at 15:31, Joerg Roedel wrote: > > Hi Filippo, > > please change the subject to: > > iommu/vt-d: Don't be too aggressive when clearing one context entry > > to follow the convention used in the iommu-tree. Another comment below. Will do. >

[RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

2017-08-31 Thread Yisheng Xie
From: Jean-Philippe Brucker Platform device can realise SVM function by using the stall mode. That is to say, when device access a memory via iova which is not populated, it will stalled and when SMMU try to translate this iova, it also will stall and meanwhile

[RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters

2017-08-31 Thread Yisheng Xie
From: Jean-Philippe Brucker Document the bindings for stall and PASID capable platform devices. Signed-off-by: Jean-Philippe Brucker --- Documentation/devicetree/bindings/iommu/iommu.txt | 13 + 1 file changed, 13

[RFC PATCH 3/6] ACPI: IORT: Add stall and pasid properties to iommu_fwspec

2017-08-31 Thread Yisheng Xie
According to ACPI IORT spec, named component specific data has a node flags field whoes bit0 is for Stall support. However, it do not have any field for pasid bit. As PCIe SMMU support 20 pasid bits, this patch suggest to use 5 bits[5:1] in node flags field for pasid bits which means we can have

[RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec

2017-08-31 Thread Yisheng Xie
From: Jean-Philippe Brucker Add stall and pasid properties to iommu_fwspec. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/of_iommu.c | 11 +++ include/linux/iommu.h| 2 ++ 2 files changed, 12 insertions(+)

[RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq

2017-08-31 Thread Yisheng Xie
When SMMU do not support SVM feature, however the master support SVM, which means matser can stall and with mult-pasid number, then the user can bind a task to device using API like iommu_bind_task(). however, when device trigger a stall mode fault i will cause panic: [ 106.996087] Unable to

[RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

2017-08-31 Thread Yisheng Xie
Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: https://www.spinics.net/lists/arm-kernel/msg565155.html But for some platform devices(aka on-chip integrated devices), there is also SVM requirement, which works based on the SMMU stall mode. Jean-Philippe has prepared a

[RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

2017-08-31 Thread Yisheng Xie
It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which means we should not disable stall mode if stall/terminate mode is not configuable. Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which means if stall mode is force we should always set CD.S. This patch add