Hi Will,
On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
> device *dev)
>* IOMMU driver.
>*/
> if (!group->default_domain) {
> - group->default_domain = __iommu_domain_alloc(d
On Fri, Mar 10, 2017 at 08:49:31PM +, Will Deacon wrote:
> Will Deacon (5):
> iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
> iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains
> iommu/arm-smmu-v3: Make arm_smmu_install_ste_for_dev return void
> iom
On Tue, Mar 21, 2017 at 04:42:41PM +, Will Deacon wrote:
> Hi Joerg,
>
> On Tue, Mar 21, 2017 at 04:46:24PM +0100, Joerg Roedel wrote:
> > On Fri, Mar 10, 2017 at 08:49:31PM +, Will Deacon wrote:
> > > Will Deacon (5):
> > > iommu/arm-smmu: Restri
On Tue, Mar 21, 2017 at 05:21:37PM +, Will Deacon wrote:
> On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
> > On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> > > @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
Hey Magnus,
On Sun, Mar 12, 2017 at 02:38:20PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: r8a7796 support V3
>
> [PATCH v3 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH v3 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH v3 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT ma
on top of renesas-drivers-2017-01-24-v4.10-rc5
>
> drivers/iommu/ipmmu-vmsa.c | 59
> +++-
> drivers/iommu/of_iommu.c | 2 -
> 2 files changed, 33 insertions(+), 28 deletions(-)
For the series:
Reviewed-by: Joerg Roedel
;
> drivers/iommu/Kconfig |1
> drivers/iommu/ipmmu-vmsa.c | 164
> +++++++++---
> 2 files changed, 157 insertions(+), 8 deletions(-)
Reviewed-by: Joerg Roedel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Mar 16, 2017 at 04:23:51PM +0200, Andy Shevchenko wrote:
> There is inconsistency in return codes across the functions called from
> detect_intel_iommu().
>
> Make it consistent and propagate return code to the caller.
>
> Signed-off-by: Andy Shevchenko
Applied all, thanks.
___
On Mon, Mar 20, 2017 at 10:17:56AM +0100, Marek Szyprowski wrote:
> Documentation specifies that SYSMMU should be in blocked state while
> performing TLB/FLPD cache invalidation, so add needed calls to
> sysmmu_block/unblock.
>
> Fixes: 66a7ed84b345d ("iommu/exynos: Apply workaround of caching fau
Hi Thierry
On Mon, Mar 20, 2017 at 08:14:31PM +0100, Thierry Reding wrote:
> I've got a series of patches that I'd like to merge for v4.12 that have
> a build-time dependency on this patch. It would therefore be great to
> get your Acked-by on this so that I can merge it through the DRM tree
> wit
On Thu, Mar 16, 2017 at 05:00:16PM +, Robin Murphy wrote:
> The introduction of reserved regions has left a couple of rough edges
> which we could do with sorting out sooner rather than later. Since we
> are not yet addressing the potential dynamic aspect of software-managed
> reservations and
On Thu, Mar 16, 2017 at 05:00:19PM +, Robin Murphy wrote:
> Now that we're applying the IOMMU API reserved regions to our IOVA
> domains, we shouldn't need to privately special-case PCI windows, or
> indeed anything else which isn't specific to our iommu-dma layer.
> However, since those aren't
On Fri, Mar 03, 2017 at 06:39:58PM +, Jean-Philippe Brucker wrote:
> Yes, it would be nice to have a common PASID allocator. But I don't
> think that a system-wide PASID space is workable for us. At the moment
> systems might have a few identical devices all supporting 20 bits of
> PASID. But c
On Mon, Feb 27, 2017 at 07:54:35PM +, Jean-Philippe Brucker wrote:
> It is an important distinction because, if the IOMMU driver reassigns a
> PASID while the IOMMU still holds pending PPR targeting that PASID
> internally, the PPR will trigger a fault in the wrong address space.
The IOMMU dri
Hi Jean-Philippe,
On Mon, Feb 27, 2017 at 07:54:33PM +, Jean-Philippe Brucker wrote:
> +extern int iommu_set_svm_ops(struct device *dev,
> + const struct iommu_svm_ops *svm_ops);
> +extern int iommu_bind_task(struct device *dev, struct task_struct *task,
> +
On Wed, Mar 22, 2017 at 07:36:52PM +0100, Thierry Reding wrote:
> *sigh* I think I messed up the #ifdef line. The attached .config has
> CONFIG_IOMMU_IOVA=m, which means that the #ifdef won't be true. I think
> the proper fix would be to:
>
> -#ifdef CONFIG_IOMMU_IOVA
> +#ifdef IS_ENABLED(CONFIG_I
On Wed, Mar 22, 2017 at 06:31:01PM +, Jean-Philippe Brucker wrote:
> The problem might be too tied to the specifics of the SMMU. As implemented
> in this series, the normal flow for a PPR with the SMMU is the following:
>
> (1) PCI device issues a PPR for PASID 1
> (2) The PPR is queued by the
On Wed, Mar 22, 2017 at 06:38:50PM +, Will Deacon wrote:
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
On Thu, Mar 23, 2017 at 01:37:41PM +, Jean-Philippe Brucker wrote:
> On 22/03/17 22:53, Joerg Roedel wrote:
> > That can't happen, when the device driver does its job right. It has to
> > shut down the context which causes the PPR requests for the PASID on the
>
On Thu, Mar 23, 2017 at 03:52:14PM +, Jean-Philippe Brucker wrote:
> On 23/03/17 14:30, Joerg Roedel wrote:
> > Are you sure about the meaning of the stop-marker? Can you point me to
> > where it is specified?
>
> The concept is introduced in the PCI ECN that a
On Thu, Mar 23, 2017 at 05:03:46PM +, Jean-Philippe Brucker wrote:
> On 23/03/17 16:52, Joerg Roedel wrote:
> > Thanks for that, I have a closer look. Is that stopper packet visible to
> > software (e.g. is an entry created in the queue)?
>
> As far as I understand, it s
fixes for IO/TLB flushing code on ARM Exynos platforms
--------
Joerg Roedel (1):
Merge branch 'for-joerg/arm-smmu/fixes' of
git://git.kernel.org/.../will/linux into iommu/fixes
Koos Vriezen (1):
iommu/vt-d: Fix NULL po
On Fri, Mar 24, 2017 at 07:08:47PM +, Jean-Philippe Brucker wrote:
> On 24/03/17 11:00, Joerg Roedel wrote:
> > The document you posted is an addition to the spec, so we can't rely on
> > a stop marker being sent by a device when it shuts down a context.
> > Curre
From: Joerg Roedel
When booting into a kexec kernel with intel_iommu=off, and
the previous kernel had intel_iommu=on, the IOMMU hardware
is still enabled and gets not disabled by the new kernel.
This causes the boot to fail because DMA is blocked by the
hardware. Disable the IOMMUs when we find
On Wed, Mar 29, 2017 at 08:51:53AM -0700, Jacob Pan wrote:
> On Wed, 29 Mar 2017 17:00:39 +0200
> Joerg Roedel wrote:
> > +static void intel_disable_iommus(void)
> > +{
> > + struct intel_iommu *iommu = NULL;
> > + struct dmar_drhd_unit *drhd;
> >
From: Joerg Roedel
Don't leave a stale pointer in case the device continues to
exist for some more time.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 45
From: Joerg Roedel
Instead of finding the matching IOMMU for a device using
string comparision functions, keep the pointer to the
iommu_dev in arch_data permanently populated.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 56
Hi,
here is a small patch-set for the omap-iommu driver to make
it use new features of the iommu-core. Please review.
Thanks,
Joerg
Joerg Roedel (5):
iommu/omap: Move data structures to omap-iommu.h
iommu/omap: Permanently keep iommu_dev pointer in arch_data
iommu/omap: Set dev
From: Joerg Roedel
The internal data-structures are scattered over various
header and C files. Consolidate them in omap-iommu.h.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 16
drivers/iommu/omap-iommu.h | 32
From: Joerg Roedel
Support for IOMMU groups will become mandatory for drivers,
so add it to the omap iommu driver.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 43 +--
drivers/iommu/omap-iommu.h | 1 +
2 files changed, 42 insertions
From: Joerg Roedel
Modify the driver to register individual iommus and
establish links between devices and iommus in sysfs.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 25 +
drivers/iommu/omap-iommu.h | 2 ++
2 files changed, 27 insertions(+)
diff
From: Joerg Roedel
Make use of the iommu_device_register() interface.
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu_v1.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index
From: Joerg Roedel
Register hardware IOMMUs seperatly with the iommu-core code
and add a sysfs representation of the iommu topology.
Signed-off-by: Joerg Roedel
---
drivers/iommu/rockchip-iommu.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git
On Fri, Mar 31, 2017 at 02:13:13PM +0100, Robin Murphy wrote:
> I was assuming this would go through the IOMMU tree if there were no
> problems and the feedback was good, and that would seem to be the case.
> I'm pleasantly surprised that this series doesn't even conflict at all
> with my other iom
On Fri, Mar 31, 2017 at 03:46:04PM +0100, Robin Murphy wrote:
> Robin Murphy (3):
> iommu/dma: Convert to address-based allocation
> iommu/dma: Clean up MSI IOVA allocation
> iommu/dma: Plumb in the per-CPU IOVA caches
>
> drivers/iommu/dma-iommu.c | 176
> -
Hey Heiko,
On Mon, Apr 03, 2017 at 11:56:59AM +0200, Heiko Stübner wrote:
> In general works, and I still keep a working iommu-based display :-)
> I can also see my two vop iommus under /sys/class/iommu now.
Great, thanks for testing that patch!
> Links in the devices subdirectory do not work th
On Mon, Apr 03, 2017 at 01:11:01PM +0200, Heiko Stübner wrote:
> ok, so you can at least add my
> Tested-by: Heiko Stuebner
>
> on the patch
Added and applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundati
On Mon, Mar 27, 2017 at 11:47:07AM +0530, arindam.n...@amd.com wrote:
> From: Arindam Nath
>
> The idea behind flush queues is to defer the IOTLB flushing
> for domains for which the mappings are no longer valid. We
> add such domains in queue_add(), and when the queue size
> reaches FLUSH_QUEUE_
On Fri, Apr 07, 2017 at 01:36:20AM -0400, Nate Watterson wrote:
> Signed-off-by: Nate Watterson
> ---
> drivers/iommu/iova.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.o
Hi Suman,
On Mon, Apr 03, 2017 at 03:35:46PM -0500, Suman Anna wrote:
> > + iommu = platform_get_drvdata(pdev);
> > + if (!iommu) {
> > + of_node_put(np);
> > + return -EINVAL;
> > + }
>
> This change is causing the issues. OMAP IOMMU driver is not probed yet,
> but this
From: Joerg Roedel
Don't leave a stale pointer in case the device continues to
exist for some more time.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e9
Hi,
here is a small patch-set for the omap-iommu driver to make
it use new features of the iommu-core. Please review.
Thanks,
Joerg
Changes since v1:
* Dropped patch 2 and moved device-link and
group-handling to attach/detach_dev call-backs for
now.
Joerg
From: Joerg Roedel
Support for IOMMU groups will become mandatory for drivers,
so add it to the omap iommu driver.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 43 +--
drivers/iommu/omap-iommu.h | 1 +
2 files changed, 42 insertions
From: Joerg Roedel
The internal data-structures are scattered over various
header and C files. Consolidate them in omap-iommu.h.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 16
drivers/iommu/omap-iommu.h | 32
From: Joerg Roedel
Modify the driver to register individual iommus and
establish links between devices and iommus in sysfs.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 25 +
drivers/iommu/omap-iommu.h | 2 ++
2 files changed, 27 insertions(+)
diff
On Fri, Apr 07, 2017 at 05:02:12PM +0100, Will Deacon wrote:
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> for-joerg/arm-smmu/updates
Pulled, thanks Will.
___
iommu mailing list
iommu@l
Hi Baoquan,
On Wed, Apr 12, 2017 at 09:40:56AM +0800, Baoquan He wrote:
> Do you plan to merge this one as urgent?
>
> There's bug created about this issue on rhel, it would be great if it
> can be put in next or merged so that we can back port it.
No, I am not sending this for v4.11, because th
On Mon, Apr 10, 2017 at 04:50:55PM +0530, Sricharan R wrote:
> arch/arm64/mm/dma-mapping.c | 142
> +-
> drivers/acpi/arm64/iort.c | 48 -
> drivers/acpi/glue.c | 5 --
> drivers/acpi/scan.c | 11 ++-
>
Hi Suman,
On Wed, Apr 12, 2017 at 12:21:25AM -0500, Suman Anna wrote:
> I have taken the liberty of refreshing the series you have posted
> based on my testing and review comments. My unit tests are passing
> now with the series. I have summarized the changes below and also
> outlined the changes
On Tue, Apr 18, 2017 at 08:51:48PM +0800, zhichang.yuan wrote:
> In iommu_bus_notifier(), when action is BUS_NOTIFY_ADD_DEVICE, it will return
> 'ops->add_device(dev)' directly. But ops->add_device will return ERR_VAL, such
> as -ENODEV. These value will make notifier_call_chain() not to traverse t
On Sun, Apr 23, 2017 at 06:23:21PM +0800, Pan Bian wrote:
> From: Pan Bian
>
> In function amd_iommu_bind_pasid(), the control flow jumps to label
> out_free when pasid_state->mm and mm is NULL. And mmput(mm) is called.
> In function mmput(mm), mm is referenced without validation. This will
> res
On Mon, Apr 24, 2017 at 04:54:54PM +0100, Will Deacon wrote:
> On Fri, Apr 21, 2017 at 05:03:36PM +0800, Peng Fan wrote:
> > - sid, smmu->smr_mask_mask);
> > + mask, smmu->smr_mask_mask);
> > goto out_free;
>
> Looks like a co
On Wed, Apr 26, 2017 at 11:01:50AM +0100, Will Deacon wrote:
> Joerg: sorry, this is another one for you to pick up if possible.
Applied.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
fixed.
Please review.
Thanks,
Joerg
Joerg Roedel (4):
iommu: Include device.h in iommu.h
iommu: Move report_iommu_fault() to iommu.c
iommu: Remove pci.h include from trace/events/iommu.h
iommu: Remove trace-events include from iommu.h
arch/arm64/mm/dma-mapping.c
From: Joerg Roedel
We make use of 'struct device' in iommu.h, so include
device.h to make it available explicitly.
Re-order the other headers while at it.
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Joerg Roedel
The function is in no fast-path, there is no need for it to
be static inline in a header file. This also removes the
need to include iommu trace-points in iommu.h.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 42 ++
include
From: Joerg Roedel
It is not needed there anymore. All places needing it are
fixed.
Signed-off-by: Joerg Roedel
---
drivers/media/platform/mtk-vpu/mtk_vpu.c | 1 +
include/linux/iommu.h| 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media
From: Joerg Roedel
The include file does not need any PCI specifics, so remove
that include. Also fix the places that relied on it.
Signed-off-by: Joerg Roedel
---
arch/arm64/mm/dma-mapping.c| 1 +
drivers/iommu/fsl_pamu.h | 1 +
drivers/iommu/rockchip-iommu.c | 1 +
drivers/iommu
Hi Robert,
On Wed, Apr 26, 2017 at 04:38:13PM +0200, Robert Richter wrote:
> - pr_info("Adding device %s to group %d\n", dev_name(dev), group->id);
> + pr_info("Adding device %s to group %d, default domain type %d\n",
> + dev_name(dev), group->id,
> + group->default
From: Joerg Roedel
Currently the s390 iommu driver allocates an iommu-group for
every device that is added. But that is wrong, as there is
only one dma-table per pci-root-bus. Make all devices behind
one dma-table share one iommu-group.
Signed-off-by: Joerg Roedel
---
arch/s390/include/asm
From: Joerg Roedel
Add support for the iommu_device_register interface to make
the s390 hardware iommus visible to the iommu core and in
sysfs.
Signed-off-by: Joerg Roedel
---
arch/s390/include/asm/pci.h | 1 +
drivers/iommu/s390-iommu.c | 30 ++
2 files changed
setup code in the s390 iommu
driver needs to be updated.
These patches do this and also add support for the
iommu_device_register interface to the s390 iommu driver.
Any comments and testing appreciated.
Thanks,
Joerg
Joerg Roedel (2):
iommu/s390: Fix IOMMU groups
iommu/s390: Add
Hi Gerald,
thanks for your reply. I have some more questions, please see below.
On Thu, Apr 27, 2017 at 08:10:18PM +0200, Gerald Schaefer wrote:
> Well, there is a separate zpci_dev for each pci_dev on s390,
> and each of those has its own separate dma-table (thus not shared).
Is that true for
On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote:
> > +void zpci_destroy_iommu(struct zpci_dev *zdev)
> > +{
> > + iommu_group_put(zdev->group);
> > + zdev->group = NULL;
> > +}
>
> While the rest of this patch doesn't seem to make much of a difference to
> the current behavior,
On Fri, Apr 28, 2017 at 03:20:17PM +0200, Gerald Schaefer wrote:
> On Thu, 27 Apr 2017 23:12:32 +0200
> Joerg Roedel wrote:
> > This is the way to free an iommu-group. It was missing before probably
> > because it was unclear whether the add_device function allocated a group
&g
Hi Gerald,
On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote:
> On Thu, 27 Apr 2017 23:03:25 +0200
> Joerg Roedel wrote:
>
> > > Well, there is a separate zpci_dev for each pci_dev on s390,
> > > and each of those has its own separate dma-table (thus
On Fri, Apr 28, 2017 at 01:16:15AM +0800, Qiuxu Zhuo wrote:
> When booting a new non-kdump kernel, we have below failure message:
>
> [0.004000] DMAR-IR: IRQ remapping was enabled on dmar2 but we are not in
> kdump mode
> [0.004000] DMAR-IR: Failed to copy IR table for dmar2 from previous
On Fri, Apr 28, 2017 at 05:25:20PM +0200, Sebastian Ott wrote:
> On Fri, 28 Apr 2017, Joerg Roedel wrote:
> > That sounds special :) So will every function of a single device end up
> > as a seperate device on a seperate root-bus?
>
> Yes. That's true even for multi-fun
Hi Gerald,
On Fri, Apr 28, 2017 at 08:06:12PM +0200, Gerald Schaefer wrote:
> On Fri, 28 Apr 2017 16:55:13 +0200
> Joerg Roedel wrote:
> Also, IIRC, add_device will get called before attach_dev. Currently we
> allow to attach more than one device (apparently from different bus
; - obj = acpi_evaluate_dsm_typed(handle, dmar_hp_uuid, DMAR_DSM_REV_ID,
> + obj = acpi_evaluate_dsm_typed(handle, &dmar_hp_uuid, DMAR_DSM_REV_ID,
> func, NULL, ACPI_TYPE_BUFFER);
> if (!obj)
> return -ENODEV;
-
Andy Shevchenko (5):
iommu/dmar: Rectify return code handling in detect_intel_iommu()
iommu/dmar: Return directly from a loop in dmar_dev_scope_status()
iommu/dmar: Remove redundant assignment of ret
iommu/dmar: Remove
se_one_atsr() and
> dmar_iommu_notify_scope_dev() to handle the extra states.
>
> Signed-off-by: Thomas Gleixner
> Cc: David Woodhouse
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> ---
> drivers/iommu/intel-iommu.c |4 ++--
> 1 file changed, 2 insertions(+), 2 delet
t() to handle the
> extra states.
>
> Signed-off-by: Thomas Gleixner
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
Acked-by: Joerg Roedel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, May 03, 2017 at 05:19:40PM +0200, Matthias Brugger wrote:
> From: Simon Xue
>
> This patch makes it possible to compile the rockchip-iommu driver on
> ARM64, so that it can be used with 64-bit SoCs equipped with this type
> of IOMMU.
>
> Signed-off-by: Simon Xue
> Signed-off-by: Shunqia
On Mon, May 15, 2017 at 04:01:30PM +0100, Robin Murphy wrote:
> When __iommu_dma_map() and iommu_dma_free_iova() are called from
> iommu_dma_get_msi_page(), various iova_*() helpers are still invoked in
> the process, whcih is unwise since they access a different member of the
> union (the iova_dom
ot true for the kdump kernel since the context
> tables have been copied from the previous kernel and translations could
> have been cached ever since. So make sure to flush the IOTLB as well
> when we destroy these old copied mappings.
>
> Cc: Joerg Roedel
> Cc: David Woodho
On Thu, May 11, 2017 at 01:35:51PM +0200, Arnd Bergmann wrote:
> The mediatek iommu driver relied on an implicit include of dma-mapping.h,
> but for some reason that is no longer there in 4.12-rc1:
>
> drivers/iommu/mtk_iommu_v1.c: In function 'mtk_iommu_domain_finalise':
> drivers/iommu/mtk_iommu
any
> recovery on that device.
>
> To: Joerg Roedel
> To: linux-ker...@vger.kernel.org
> To: David Woodhouse
> Cc: Jean-Phillipe Brucker
> Cc: iommu@lists.linux-foundation.org
>
> Signed-off-by: CQ Tang
> Signed-off-by: Ashok
On Wed, May 17, 2017 at 07:29:12PM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> Checkpatch dislikes the type unsigned, so update the iommu
> domain type and consumers to use unsigned int to reduce noise.
And I hate stupid checkpatch warnings and refuse to fix them. This
clearly is one.
___
On Wed, May 17, 2017 at 07:06:16PM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V8
>
> [PATCH v8 01/08] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v8 02/08] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for
> context
> [PATCH v8 03/08] iommu/ipmmu-v
On Tue, May 16, 2017 at 12:26:48PM +0100, Robin Murphy wrote:
> When walking the rbtree, the fact that iovad->start_pfn and limit_pfn
> are both inclusive limits creates an ambiguity once limit_pfn reaches
> the bottom of the address space and they overlap. Commit 5016bdb796b3
> ("iommu/iova: Fix u
From: Joerg Roedel
Misbehaving devices can cause an endless chain of
io-page-faults, flooding dmesg and making the system-log
unusable or even prevent the system from booting.
So ratelimit the error messages about io-page-faults in a
per-device basis.
Signed-off-by: Joerg Roedel
---
drivers
Hi Linus,
The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.12-rc1
for you to fetch changes up to
Hi Arindam,
I met Tom Lendacky last week in Nuremberg last week and he told me he is
working on the same area of the code that this patch is for. His reason
for touching this code was to solve some locking problems. Maybe you two
can work together on a joint approach to improve this?
On Mon, May
On Mon, May 22, 2017 at 04:06:37PM +0100, Robin Murphy wrote:
> IORT revision C has been published with a number of new SMMU
> implementation identifiers. Since IORT doesn't have any way of falling
> back to a more generic model code, we really need Linux to know about
> these before vendors start
On Tue, May 23, 2017 at 06:31:29PM +0530, Sricharan R wrote:
> Now with IOMMU probe deferral, we return -EPROBE_DEFER
> for masters that are connected to an IOMMU which is not
> probed yet, but going to get probed, so that we can attach
> the correct dma_ops. So while trying to defer the probe of
>
On Sat, May 27, 2017 at 07:17:40PM +0530, Sricharan R wrote:
> Now with IOMMU probe deferral, we return -EPROBE_DEFER
> for masters that are connected to an IOMMU which is not
> probed yet, but going to get probed, so that we can attach
> the correct dma_ops. So while trying to defer the probe of
>
On Mon, May 22, 2017 at 06:28:51PM +0800, Peter Xu wrote:
> We do find_domain() in __get_valid_domain_for_dev(), while we do the
> same thing in get_valid_domain_for_dev(). No need to do it twice.
>
> Signed-off-by: Peter Xu
> ---
> drivers/iommu/intel-iommu.c | 16 ++--
> 1 file ch
On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote:
> Unlike the old allocator, alloc_iova_fast() will return 0 if it failed
> to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end
> up treating that as a valid address, translate it to the DMA_ERROR_CODE
> that they would
On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote:
> +- ats-supported: if present, the root complex supports the Address
> + Translation Service (ATS). It is able to interpret the AT field in PCIe
> + Transaction Layer Packets, and forward Translation Completions or
> + Inval
On Wed, May 24, 2017 at 07:01:42PM +0100, Jean-Philippe Brucker wrote:
> * TLB invalidation by range is batched and committed with a single sync.
> Batching ATC invalidation is inconvenient, endpoints limit the number of
> inflight invalidations. We'd have to count the number of invalidations
>
Hey Tom,
On Mon, Jun 05, 2017 at 02:52:35PM -0500, Tom Lendacky wrote:
> After reducing the amount of MMIO performed by the IOMMU during operation,
> perf data shows that flushing the TLB for all protection domains during
> DMA unmapping is a performance issue. It is not necessary to flush the
> T
Hey Tom,
On Wed, Jun 07, 2017 at 09:03:15AM -0500, Tom Lendacky wrote:
> I was able to run your patches in combination with the first two patches
> that I submitted and the results look good. Let me know if you'd like
> me to resubmit the series minus the third patch.
Thanks a lot for testing th
queue
locks.
Regards,
Joerg
Joerg Roedel (7):
iommu/amd: Rip out old queue flushing code
iommu/amd: Add per-domain flush-queue data structures
iommu/amd: Make use of the per-domain flush queue
iommu/amd: Add locking to per-domain flush-queue
iommu/amd: Add flush counters to struct
From: Joerg Roedel
Make the flush-queue per dma-ops domain and add code
allocate and free the flush-queues;
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 69 +++
1 file changed, 69 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c
From: Joerg Roedel
The queue flushing is pretty inefficient when it flushes the
queues for all cpus at once. Further it flushes all domains
from all IOMMUs for all CPUs, which is overkill as well.
Rip it out to make room for something more efficient.
Signed-off-by: Joerg Roedel
---
drivers
From: Joerg Roedel
Fill the flush-queue on unmap and only flush the IOMMU and
device TLBs when a per-cpu queue gets full.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 60 +++
1 file changed, 56 insertions(+), 4 deletions(-)
diff
From: Joerg Roedel
With locking we can safely access the flush-queues of other
cpus.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 6a5c858..9aa2735 100644
From: Joerg Roedel
We can use queue_ring_free_flushed() instead, so remove this
redundancy.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu
From: Joerg Roedel
Add a timer to each dma_ops domain so that we flush unused
IOTLB entries regularily, even if the queues don't get full
all the time.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 84 +--
1 file changed, 67 inser
101 - 200 of 3797 matches
Mail list logo
