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 a/drivers/iommu/dma-iommu.c b/drivers/iommu
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
Cc: Suravee Suthikulpa
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
Cc: David Woodhouse
C
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 gotten so far
Tested as b
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 secondary MMU invalidation
>>>
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 ptep_clear_
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
> ---
>
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 each
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 bloc
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.
Following
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 aroun
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 t
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
cosmet
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
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 us
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 mul
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
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
Datum: 31.08.17
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 iommu_device_sysfs
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 a
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: David Woodhouse
Cc: Joerg Roedel
Cc: Ja
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 entry. This is a tad too aggressive.
>> Invalidate the context c
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.
> On Mon, Aug 28, 2
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 send an event to CPU via MSI.
Afte
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 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/
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 3
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(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
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 hand
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
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 ARM_S
30 matches
Mail list logo
