/amd_iommu_v2.c | 184 +-
Shortlog:
Joerg Roedel (5):
iommu/amd: Don't access IOMMUv2 state_table directly
iommu/amd: Convert IOMMUv2 state_table into state_list
iommu/amd: Implement mmu_notifier_release call-back
iommu/amd: R
Hi Linus,
The following changes since commit d6d211db37e75de2ddc3a4f979038c40df7cc79c:
Linux 3.15-rc5 (2014-05-09 13:10:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v3.15-rc5
for you to fetch changes up to
On Thu, May 15, 2014 at 12:40:43PM +0200, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart
> ---
> drivers/iommu/ipmmu-vmsa.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 49e00f7..49dbedd 1006
On Tue, May 20, 2014 at 11:18:21PM +0200, Joerg Roedel wrote:
> Joerg Roedel (5):
> iommu/amd: Don't access IOMMUv2 state_table directly
> iommu/amd: Convert IOMMUv2 state_table into state_list
> iommu/amd: Implement mmu_notifier_release call-back
>
On Fri, May 16, 2014 at 03:39:40PM +0800, Vaughan Cao wrote:
> amd_iommu_rlookup_table[devid] != NULL is already guaranteed by check_device
> called before, it's fine to attach device at this point.
>
> Signed-off-by: Vaughan Cao
> ---
> drivers/iommu/amd_iommu.c | 6 --
> 1 file changed, 6
On Thu, May 22, 2014 at 09:50:54AM +0530, Sachin Kamat wrote:
> EXYNOS_DEV_SYSMMU symbol is not defined anywhere and prevents building
> the Exynos driver. Remove it.
>
> Signed-off-by: Sachin Kamat
Applied all 3, thanks.
___
iommu mailing list
iommu@
cab Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Mon, 26 May 2014 13:07:01 +0200
Subject: [PATCH] arm/ipmmu-vmsa: Fix compile error
The function arm_iommu_create_mapping lost the order
parameter. Remove it from this IOMMU driver too to make it
build.
Signed-off-by: Joerg Roedel
---
dr
On Thu, May 29, 2014 at 03:45:47PM +0200, Paul Bolle wrote:
> On Mon, 2014-05-26 at 11:39 +0200, Joerg Roedel wrote:
> > On Fri, May 16, 2014 at 03:39:40PM +0800, Vaughan Cao wrote:
> > > amd_iommu_rlookup_table[devid] != NULL is already guaranteed by
> > > check_devic
On Tue, May 27, 2014 at 06:18:42PM +0800, Kefeng Wang wrote:
> Use devm_ioremap_resource() to make the code simpler, drop unused variable,
> redundant return value check, and error-handing code.
>
> Signed-off-by: Kefeng Wang
> ---
> drivers/iommu/msm_iommu_dev.c | 38 +++--
On Tue, Jun 03, 2014 at 03:24:20PM -0600, Shuah Khan wrote:
> On 06/01/2014 01:01 AM, Eli Billauer wrote:
> I see the value of this interface in unmap case, this type of wrapper
> can release dma buffers, drivers neglected to release leaving dangling
> buffers.
>
> However, driver writers should g
On Wed, Jun 04, 2014 at 10:04:08AM -0400, Tejun Heo wrote:
> Hmmm? Don't we have drivers which map dma buffers on device init and
> release them on exit? For dynamic usages, its usefulness is limited
> especially given that dynamic tracking of buffers usually would
> involve tracking of other inf
Hi,
On Wed, Jun 04, 2014 at 06:03:36PM +0300, Eli Billauer wrote:
> I believe that I need a managed dma_map_single() my own driver,
> which doesn't fall in the case of a single use: The driver allocates
> its buffers with __get_free_pages() (or the to-be managed version of
> it). Then it cuts the
fic typedef
iommu/exynos: Enhanced error messages
documentation: iommu: Add binding document of Exynos System MMU
iommu/exynos: Support for device tree
iommu/exynos: Turn on useful configuration options
iommu/exynos: Apply workaround of caching fault page table entries
Hi Alex,
On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote:
> Alex Williamson (16):
> PCI: Add DMA alias iterator
> PCI: define pci_dev_flags as bit shifts
> PCI: quirk pci_for_each_dma_alias()
> PCI: quirk dma_alias_devfn for Ricoh devices
> PCI: quirk
On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote:
> On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote:
> > With an ARM SMMU, interrupt remapping should always be safe from the
> > SMMU's point of view, as it is properly handled by the GIC.
> >
> > Signed-off-by: Anto
Hi Laurent,
On Mon, May 26, 2014 at 12:08:37PM +0200, Laurent Pinchart wrote:
> > Skipped this one because it didn't apply. The others are applied.
>
> Thank you. I'll rebase the patch on top of your tree as soon as you publish
> the related branch and resubmit.
What happened to this patch? And
On Thu, Jun 12, 2014 at 04:12:18PM -0600, Alex Williamson wrote:
> Alex Williamson (3):
> iommu: Add sysfs support for IOMMUs
> iommu/intel: Make use of IOMMU sysfs support
> iommu/amd: Add sysfs support
I like the general approach. But why do you only enable the x86 iommus?
Some
On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote:
> MSIs look just like memory accesses made by the device, so the SMMU
> will translate them to point at the GIC ITS (doorbell). The ITS then
> has tables to work out how to route the MSI.
>
> So, if IOMMU_CAP_INTR_REMAP is simply suppose
On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote:
> Ok, thanks. In which case, I think this is really a combined property of
> the SMMU and the interrupt controller, so we might need some extra code
> so that the SMMU can check that the interrupt controller for the device
> is also capab
On Tue, Jun 17, 2014 at 10:29:19PM +0800, Jeff Liu wrote:
> From: Jie Liu
>
> kset_create_and_add() has been fixed to return the actual error
> code ptr rather than NULL, so update iommu_init() to check the
> return value via IS_ERR() accordingly.
>
> Cc: Joerg Roedel
>
On Fri, Jun 20, 2014 at 03:08:06PM +0800, Jiang Liu wrote:
> Function dmar_iommu_notify_scope_dev() makes a wrong assumption that
> there's one RMRR for each PCI device at most, which causes DMA failure
> on some HP platforms. So enhance dmar_iommu_notify_scope_dev() to
> handle multiple RMRRs for
per
device
* Fix a small race that was left in the mmu_notifier handling in
the AMD IOMMUv2 driver
Jiang Liu (1):
iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
Joerg Roedel
Hi Linus,
On Fri, Jun 27, 2014 at 07:03:45PM -0700, Linus Torvalds wrote:
> this email was in my spam-box. No real indication as to why, although
> the usual suspect is
>
>Received-SPF: none (google.com: j...@8bytes.org does not designate
> permitted sender hosts) client-ip=85.214.48.195;
H
On Mon, Jun 30, 2014 at 02:41:24PM +, Gabbay, Oded wrote:
> I did face some problems regarding the amd IOMMU v2 driver, which
> changed its behavior (see commit "iommu/amd: Implement
> mmu_notifier_release call-back") to use mmu_notifier_release and did
> some "bad things" inside that
> notifie
On Mon, Jun 30, 2014 at 12:06:05PM -0400, Jerome Glisse wrote:
> No this patch does not duplicate it. Current user of mmu_notifier
> rely on file close code path to call mmu_notifier_unregister. New
> code like AMD IOMMUv2 or HMM can not rely on that. Thus they need
> a way to call the mmu_notifer_
On Mon, Jun 30, 2014 at 02:35:57PM -0400, Jerome Glisse wrote:
> We do intend to tear down all secondary mapping inside the relase
> callback but still we can not cleanup all the resources associated
> with it.
>
And why can't you cleanup the other resources in the file close path?
Tearing down th
Hi Andrew,
On Mon, Jun 30, 2014 at 06:57:48PM +, Lewycky, Andrew wrote:
> As an aside we found another small issue: amd_iommu_bind_pasid calls
> get_task_mm. This bumps the mm_struct use count and it will never be
> released. This would prevent the buggy code path described above from
> ever r
On Tue, Jul 01, 2014 at 09:29:49AM +, Gabbay, Oded wrote:
> In the KFD, we need to maintain a notion of each compute process.
> Therefore, we have an object called "kfd_process" that is created for
> each process that uses the KFD. Naturally, we need to be able to track
> the process's shutdown
On Tue, Jul 01, 2014 at 03:33:44PM -0400, Jerome Glisse wrote:
> On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> > No, its not in this case. The file descriptor is used to connect a
> > process address space with a device context. Thus without the mappings
> >
Hi David,
On Wed, Apr 30, 2014 at 11:49:33AM +0100, David Woodhouse wrote:
> There could be all kinds of existing mappings in the DMA page tables,
> and I'm not sure it's safe to preserve them. What prevents the crashdump
> kernel from trying to use any of the physical pages which are
> accessible
Hi Jerome,
On Thu, Jul 03, 2014 at 02:30:26PM -0400, Jerome Glisse wrote:
> Joerg do you still object to this patch ?
Yes.
> Again the natural place to call this is from mmput and the fact that many
> other subsystem already call in from there to cleanup there own per mm data
> structure is a te
On Tue, May 20, 2014 at 08:37:48PM +0800, Yijing Wang wrote:
> Move up the no_iommu and dmar_disabled check, avoid the
> useless initialization for dmar.
>
> Signed-off-by: Yijing Wang
> ---
> drivers/iommu/intel-iommu.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff
7af32ea18bc3508cdb0007 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Fri, 4 Jul 2014 11:19:10 +0200
Subject: [PATCH] iommu/vt-d: Don't use magic number in dma_pte_superpage
Use the already defined DMA_PTE_LARGE_PAGE for testing
instead of hardcoding the value again.
Signed-off-by: Joe
On Mon, May 26, 2014 at 08:14:06PM +0800, Yijing Wang wrote:
> suppress compiler warnings:
> drivers/iommu/intel-iommu.c: In function ‘device_to_iommu’:
> drivers/iommu/intel-iommu.c:673: warning: ‘segment’ may be used uninitialized
> in this function
> drivers/iommu/intel-iommu.c: In function ‘ge
On Thu, Jul 03, 2014 at 09:51:12AM -0600, Alex Williamson wrote:
> Alex Williamson (7):
> iommu: Remove pci.h
> iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups
> iommu/intel: Update to use PCI DMA aliases
> iommu/intel: Use iommu_group_get_for_dev()
> iommu/a
On Thu, Jun 12, 2014 at 04:12:18PM -0600, Alex Williamson wrote:
> Alex Williamson (3):
> iommu: Add sysfs support for IOMMUs
> iommu/intel: Make use of IOMMU sysfs support
> iommu/amd: Add sysfs support
>
>
> Documentation/ABI/testing/sysfs-class-iommu| 17 +++
> ...
On Sat, Jun 14, 2014 at 11:58:34PM +0200, Fabian Frederick wrote:
> use mm.h definition
>
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> Signed-off-by: Fabian Frederick
> ---
> drivers/iommu/omap-iovmm.c | 10 +-
> 1 file changed, 5 insertions(+),
On Tue, Jun 24, 2014 at 07:27:15PM +0530, Varun Sethi wrote:
> /* window size is 2^(WSE+1) bytes */
> - return __ffs(addrspace_size) - 1;
> + return fls64(addrspace_size) - 2;
This looks bogus, why do you replace ffs (find-first-bit) by fls
(find-last-bit)?
Joerg
Hmm,
On Tue, Jun 24, 2014 at 07:27:16PM +0530, Varun Sethi wrote:
> - old_domain_info = find_domain(dev);
> + old_domain_info = dev->archdata.iommu_domain;
> if (old_domain_info && old_domain_info->domain != dma_domain) {
> spin_unlock_irqrestore(&device_domain_lock, fl
On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> Add an IOMMU device registry for drivers to register with and implement
> a method for users of the IOMMU API to attach to an IOMMU device. This
> allows to support deferred probing and gives the IOMMU API a convenient
> hook to perf
On Sun, Jun 29, 2014 at 10:01:26AM +0200, Fabian Frederick wrote:
> Fix checkpatch warning:
> WARNING: kfree(NULL) is safe this check is probably not required
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfo
On Thu, Jul 03, 2014 at 03:03:01PM +0200, Chi Pham wrote:
> Added explicit void declarations to zero-argument function headers.
> The following coccinelle script was used:
> @addvoid@
> identifier f;
> @@
>
> f(
> + void
> ) { ... }
>
> Signed-off-by: Chi Pham a
Applied, thanks.
> ---
> drive
On Tue, Jun 24, 2014 at 07:27:14PM +0530, Varun Sethi wrote:
> This patch set contains fixes for the PAMU driver.
> The patches are based on 3.16-rc1.
>
> Varun Sethi (3):
> Fix PAMU window size check.
> Fix the device domain attach condition.
> Fix the error condition during iommu group c
On Fri, Jun 27, 2014 at 09:03:12AM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This structure is read-only data and should never be modified.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - add missing hunk from include/device.h
>
> drivers/iommu/amd_iommu.c |
On Mon, Jul 07, 2014 at 02:31:36PM -0600, Alex Williamson wrote:
> 0-day kernel build testing reports:
>
>arch/x86/kvm/x86.o: In function `iommu_device_destroy':
> >> (.text+0x7a0a): multiple definition of `iommu_device_destroy'
>arch/x86/kvm/../../../virt/kvm/vfio.o:vfio.c:(.text+0x490):
On Tue, Jul 08, 2014 at 05:30:16PM +0300, Oded Gabbay wrote:
> From: Alexey Skidanov
>
> The pasid wasn't properly initialized before caling to invalid PPR calback
>
> Signed-off-by: Alexey Skidanov
> Signed-off-by: Oded Gabbay
> ---
> drivers/iommu/amd_iommu_v2.c | 1 +
> 1 file changed, 1 i
From: Joerg Roedel
This is used to signal the ppr_notifer function that no more
faults should be processes on this pasid_state. This way we
can keep the pasid_state safely in the state-table so that
it can be freed in the amd_iommu_unbind_pasid() function.
This allows us to not hold a reference
file changed, 71 insertions(+), 33 deletions(-)
Shortlog:
Joerg Roedel (9):
iommu/amd: Fix typo in amd_iommu_v2 driver
iommu/amd: Don't call mmu_notifer_unregister in __unbind_pasid
iommu/amd: Don't free pasid_state in mn_release path
iommu/amd: Get rid of __un
From: Joerg Roedel
The mmu_notifier state is part of pasid_state so it can't be
freed in the mn_release path. Free the pasid_state after
mmu_notifer_unregister has completed.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 10 +++---
1 file ch
From: Joerg Roedel
In case we are not able to allocate a fault structure a
reference to the pasid_state will be leaked. Fix that by
dropping the reference in the error path in case we hold
one.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c |4
1
From: Joerg Roedel
On the error path of amd_iommu_bind_pasid() we call
mmu_notifier_unregister() for cleanup. This calls
mn_release() which calls the users inv_ctx_cb function if
one is available. Since the pasid is not set up yet there is
nothing the user can to tear down in this call-back. So
From: Joerg Roedel
Since we are only caring about the lifetime of the mm_struct
and not the task we can't safely keep a reference to it. The
reference is also not needed anymore, so remove that code
entirely.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu
From: Joerg Roedel
Unbind_pasid is only called from mn_release which already
has the pasid_state. Use this to simplify the unbind_pasid
path and get rid of __unbind_pasid.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 17 ++---
1 file
From: Joerg Roedel
Fix typo in a comment.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_v2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index 92fb77c..0e29f6f 100644
--- a/drivers/iommu
From: Joerg Roedel
With mmu_notifiers we don't need to hold a reference to the
mm_struct during the time the pasid is bound to a device. We
can rely on the .mn_release call back to inform us when the
mm_struct goes away.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/
From: Joerg Roedel
This function is called only in the mn_release() path, so
there is no need to unregister the mmu_notifer here.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu
On Thu, Jul 10, 2014 at 11:33:47AM +0100, Will Deacon wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
On Mon, Jun 30, 2014 at 09:51:51AM -0700, Olav Haugan wrote:
> +int iommu_map_range(struct iommu_domain *domain, unsigned int iova,
> + struct scatterlist *sg, unsigned int len, int prot)
> +{
> + if (unlikely(domain->ops->map_range == NULL))
> + return -ENODEV;
> +
Hi Linus,
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:
Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v3.16-rc5
for you to fetch changes up to
On Mon, Jul 21, 2014 at 11:19:29PM -0700, Tony Lindgren wrote:
> > Tony, is there still time to get this (and especially patch 2/3, which
> > touches
> > arch/ code) in v3.17 ?
>
> Yes as long as Joerg is OK to merge that branch in :)
Fine with me, I can take only patch 1 or all 3 into my arm/o
On Tue, Jul 22, 2014 at 08:27:19AM -0600, Greg Edwards wrote:
> get_irte() can race with free_irte() and dereference a NULL iommu
> pointer.
Have you seen any real occurance of this race? Get_irte is called in the
set_affinity path, how can that race with the irq being freed?
Joerg
On Wed, Jul 23, 2014 at 08:49:17AM -0600, Greg Edwards wrote:
> On Wed, Jul 23, 2014 at 04:40:24PM +0200, Joerg Roedel wrote:
> > On Tue, Jul 22, 2014 at 08:27:19AM -0600, Greg Edwards wrote:
> >> get_irte() can race with free_irte() and dereference a NULL iommu
> >> poi
On Fri, Jul 11, 2014 at 02:19:40PM +0800, Jiang Liu wrote:
> On Intel platforms, an IO Hub (PCI/PCIe host bridge) may contain DMAR
> units, so we need to support DMAR hotplug when supporting PCI host
> bridge hotplug on Intel platforms.
>
> According to Section 8.8 "Remapping Hardware Unit Hot Plu
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
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
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
important that this
happens before invalidate_range_end() is called.
Any comments and review appreciated!
Thanks,
Joerg
Joerg Roedel (3):
mmu_notifier: Add mmu_notifier_invalidate_range()
mmu_notifier: Call mmu_notifier_invalidate_range() from VMM
mmu_notifier: A
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
Hi Andrew,
On Thu, Jul 24, 2014 at 04:33:03PM -0700, Andrew Morton wrote:
> On Thu, 24 Jul 2014 16:35:38 +0200 Joerg Roedel wrote:
> >
> > Any comments and review appreciated!
>
> It looks pretty simple and harmless.
>
> I assume the AMD IOMMUv2 driver actually uses
On Fri, Jul 25, 2014 at 01:16:39PM -0700, Jesse Barnes wrote:
> > To allow managing external TLBs the MMU-notifiers need to
> > catch the moment when pages are unmapped but not yet freed.
> > This new notifier catches that moment and notifies the
> > interested subsytem when pages that were unmappe
On Fri, Jul 25, 2014 at 02:42:13PM -0700, Jesse Barnes wrote:
> On Fri, 25 Jul 2014 23:38:06 +0200
> Joerg Roedel wrote:
> > I though about removing the need for invalidate_range_end too when
> > writing the patches, and possible solutions are
> >
> > 1) Add
On Wed, Jul 23, 2014 at 04:00:47PM +0200, Laurent Pinchart wrote:
> Thank you. Assuming there's currently no conflict to be resolved, I believe
> the easiest would be for both you and Tony to merge my branch in your trees.
Okay, I applied the patches to my arm/omap branch. I will push them out
to
On Wed, Jul 23, 2014 at 10:13:26AM -0600, Greg Edwards wrote:
> A user process setting the CPU affinity of an IRQ for a KVM
> direct-assigned device via /proc/irq//smp_affinity can race with
> the IRQ being released by QEMU, resulting in a NULL iommu pointer
> dereference in get_irte().
Maybe I wa
On Fri, Jul 11, 2014 at 02:19:24PM +0800, Jiang Liu wrote:
> Patch 1-13 are bugfixes and code improvement for current drivers.
Okay, I applied these for now (1-13 only) so that you don't have to
rebase everything next time.
> Patch 14-17 enhances DMAR framework to support hotplug
> Patch 18 enhan
On Fri, Jul 04, 2014 at 03:01:08PM +0530, Tushar Behera wrote:
> For IOMMU to use on Exynos platforms, we need to enable ARM_DMA_USE_IOMMU. It
> would be better to select it by default when EXYNOS_IOMMU is enabled.
>
> Signed-off-by: Tushar Behera
Applied, thanks. Please always Cc me directly on
On Thu, Jul 03, 2014 at 09:57:02AM -0600, Alex Williamson wrote:
> The user of the IOMMU API domain expects to have full control of
> the IOVA space for the domain. RMRRs are fundamentally incompatible
> with that idea. We can neither map the RMRR into the IOMMU API
> domain, nor can we guarantee
ts and review appreciated!
Thanks,
Joerg
Joerg Roedel (3):
mmu_notifier: Add mmu_notifier_invalidate_range()
mmu_notifier: Call mmu_notifier_invalidate_range() from VMM
mmu_notifier: Add the call-back for mmu_notifier_invalidate_range()
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 | 37 -
mm/mmu_notifier.c| 25
From: Joerg Roedel
This notifier closes two important gaps 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
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
On Wed, Jul 30, 2014 at 03:23:50PM +0200, Thierry Reding wrote:
> I think there weren't any comments left for me to address and I've
> mostly been waiting for Joerg to pick it up.
>
> Joerg, can you take this through the iommu tree for 3.17? Will acked
> this, but perhaps you were waiting for an A
From: Joerg Roedel
With calling te mmu_notifier_register function we hold a
reference to the mm_struct that needs to be released in
mmu_notifier_unregister. This is true even if the notifier
was already unregistered from exit_mmap and the .release
call-back has already run.
So make sure we call
From: Joerg Roedel
All calls to this call-back are wrapped with
mmu_notifer_invalidate_range_start()/end(), making this
notifier pretty useless, so remove it.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 9 -
1 file changed, 9 deletions
From: Joerg Roedel
The references to the device state are not dropped
everywhere. This might cause a dead-lock in
amd_iommu_free_device(). Fix it.
Signed-off-by: Joerg Roedel
Tested-by: Oded Gabbay
---
drivers/iommu/amd_iommu_v2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a
From: Joerg Roedel
amd_iommu_pasid_bind -> amd_iommu_bind_pasid
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_v2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index 2de13be..5f578e8 100644
--
On Thu, Jul 31, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> It looks like this hasn't been applied yet, so I can send out a v5
> shortly with the requested changes addressed.
Yes, please send a v5 with the requested changes and all Reviewed-bys
and Acked-bys this got so far. I'll take it int
On Tue, Jul 29, 2014 at 11:21:58AM -0600, Greg Edwards wrote:
> [ 6638.327851] BUG: unable to handle kernel NULL pointer dereference at
> 0090
> [ 6638.335955] IP: [] intel_ioapic_set_affinity+0x82/0x1b0
> [ 6638.343012] PGD 99172e067 PUD 1026979067 PMD 0
> [ 6638.347858] Oops: [
On Thu, Jul 31, 2014 at 12:43:03PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra S
On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
> >
> > Applied, thanks everyone.
>
> Really?
>
> Gee, thanks for giving people a chance to reply with acks. It's
> considered polite to do so when there has been outstanding questions.
Its not pushed yet, I can still make changes.
On Thu, Jul 31, 2014 at 10:14:08AM -0700, Olof Johansson wrote:
> On Thu, Jul 31, 2014 at 9:36 AM, Joerg Roedel wrote:
> > On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
> >> >
> >> > Applied, thanks everyone.
> >>
> >> Really?
From: Joerg Roedel
This BUG_ON is easy to trigger with device-hotplug (e.g.
SR-IOV). The device_notifier function in the Intel IOMMU
driver listens to the BUS_NOTIFY_DEL_DEVICE event and frees
the domain for the device if it is reveived.
But this event is triggered before the device driver is
On Mon, Aug 04, 2014 at 01:42:05PM +0200, Borislav Petkov wrote:
> It is always questionable when people remove BUG_ONs because relaxing
> assertions sound like a temporary fix more often than not. Sounds to me
> that the original commit which deals with BUS_NOTIFY_DEL_DEVICE needs to
> try again w
to
> try again with the fix. :-)
Actually, as I thought about it again, there is a better fix for this
issue that does not require to remove the BUG_ON :) See attached patch:
>From 57e2519d5b6e4d8ee840a921300d201ff742c826 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Tue, 5 Aug 2014
u_enable/disable_translation to return void
iommu/vt-d: Simplify intel_unmap_sg() and kill duplicated code
iommu/vt-d: Introduce helper domain_pfn_within_range() to simplify code
iommu/vt-d: Introduce helper function iova_size() to improve code
readability
iommu/vt-d:
On Wed, Aug 06, 2014 at 10:08:55AM -0700, Olav Haugan wrote:
> so you are suggesting that I check in "bus_set_iommu()" whether the
> driver has set the map_sg/unmap_sg function pointers or not and if not
> set it to the default? Is bus_set_iommu() the only way drivers can set
> up the callbacks?
T
your formal proposal on the Linux Plumbers website (OpenID
login required) until August 31st at:
http://www.linuxplumbersconf.org/2014/how-to-submit-microconference-discussions-topics/
Hope to see you in Düsseldorf!
Joerg Roedel and Alex Williamson
On Wed, Oct 10, 2018 at 03:49:48PM +0100, Will Deacon wrote:
> Joerg -- you can pick them up if you're still queueing patches, otherwise
> I'll include them for 4.21.
Applied to arm/smmu.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://li
ling mistake pci_endpt_partioning ->
pci_endpt_partitioning
Ganapatrao Kulkarni (1):
iommu/iova: Optimise attempts to allocate iova from 32bit address range
Gayatri Kammela (1):
iommu/vt-d: Add debugfs support to show register contents
Joerg Roedel (3):
Merge branch 'for-
On Thu, Oct 11, 2018 at 04:56:42PM +0100, Robin Murphy wrote:
> The original motivation for iommu_map_sg() was to give IOMMU drivers the
> chance to map an IOVA-contiguous scatterlist as efficiently as they
> could. It turns out that there isn't really much driver-specific
> business involved there
On Wed, Oct 17, 2018 at 11:13:22AM +0200, Simon Horman wrote:
> From: Hai Nguyen Pham
>
> Support the R-Car E3 (r8a77990) IPMMU.
>
> Signed-off-by: Hai Nguyen Pham
> Signed-off-by: Kazuya Mizuguchi
> [simon: rebased; dropped no longer required IOMMU_OF_DECLARE hunk]
> Signed-off-by: Simon Horm
501 - 600 of 3797 matches
Mail list logo
