On Thu, 24 Jul 2014 16:35:38 +0200 Joerg Roedel wrote:
> here is a patch-set to extend the mmu_notifiers in the Linux
> kernel to allow managing CPU external TLBs. Those TLBs may
> be implemented in IOMMUs or any other external device, e.g.
> ATS/PRI capable PCI devices.
>
> The problem with man
The TLB must be invalidated after unmapping memory to remove stale TLB
entries. this was supposed to be performed already, but a bug in the
driver prevented the TLB invalidate function from being called. Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/ipmmu-vmsa.c | 4 +---
1 file chan
The ARM IOMMU mapping needs to be released when attaching the device
fails. Add arm_iommu_release_mapping() to the error code path. This is
safe to call with a NULL mapping, so no specific check is needed.
Cleanup is also missing when failing to create a mapping. Jump to the
error code path in tha
When clearing PUD or PMD entries the child page table (if any) is freed
and the PUD or PMD entry is then cleared. This result in a small race
condition window during which a free page table could be accessed by the
IPMMU.
Fix it by clearing and flushing the PUD or PMD entry before freeing the
chil
Hello,
This series fixes small issues with the ipmmu-vmsa driver. Please see
individual patches for details.
If not too late, I'd like these fixes to be merged in v3.17 (after proper
review of course, or, in the worst case, after lack of review).
Laurent Pinchart (3):
iommu/ipmmu-vmsa: Cleanup
On Thu, Jul 24, 2014 at 04:35:38PM +0200, Joerg Roedel wrote:
> To solve this situation I wrote a patch-set to introduce a
> new notifier call-back: mmu_notifer_invalidate_range(). This
> notifier lifts the strict requirements that no new
> references are taken in the range between _start() and
> _
Hi,
here is a patch-set to extend the mmu_notifiers in the Linux
kernel to allow managing CPU external TLBs. Those TLBs may
be implemented in IOMMUs or any other external device, e.g.
ATS/PRI capable PCI devices.
The problem with managing these TLBs are the semantics of
the invalidate_range_start
From: Joerg Roedel
Add calls to the new mmu_notifier_invalidate_range()
function to all places if the VMM that need it.
Signed-off-by: Joerg Roedel
---
include/linux/mmu_notifier.h | 28
kernel/events/uprobes.c | 2 +-
mm/fremap.c | 2 +-
mm
From: Joerg Roedel
This notifier closes an important gap with the current
invalidate_range_start()/end() notifiers. The _start() part
is called when all pages are still mapped while the _end()
notifier is called when all pages are potentially unmapped
and already freed.
This does not allow to ma
From: Joerg Roedel
Now that the mmu_notifier_invalidate_range() calls are in
place, add the call-back to allow subsystems to register
against it.
Signed-off-by: Joerg Roedel
---
include/linux/mmu_notifier.h | 28 ++--
mm/mmu_notifier.c| 15 +++
2
On Wed, Jul 23, 2014 at 10:49:55AM -0700, Olav Haugan wrote:
> On 7/22/2014 12:45 AM, Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 05:59:22PM -0700, Olav Haugan wrote:
> >> On 7/17/2014 1:21 AM, Thierry Reding wrote:
> >>> On Wed, Jul 16, 2014 at 06:01:57PM -0700, Olav Haugan wrote:
> > [...]
On Thu, Jul 24, 2014 at 11:34:27AM +0200, Joerg Roedel wrote:
> On Wed, Jul 23, 2014 at 10:49:55AM -0700, Olav Haugan wrote:
> > Joerg, can you comment on what you envisioned when you suggested that we
> > add the fallback?
> >
>
> The problem is that we already have tons of IOMMU drivers in the
On Wed, Jul 23, 2014 at 10:49:55AM -0700, Olav Haugan wrote:
> Joerg, can you comment on what you envisioned when you suggested that we
> add the fallback?
>
The problem is that we already have tons of IOMMU drivers in the tree
which don't provide these call-backs. So adding this API extension
wi
13 matches
Mail list logo
