[PATCH 1/1] iommu/vt-d: Use real PASID for flush in caching mode

If caching mode is supported, the hardware will cache none-present or erroneous translation entries. Hence, software should explicitly invalidate the PASID cache after a PASID table entry becomes present. We should issue such invalidation with the PASID value that we have changed. PASID 0 is not

Re: [RFC 2/5] dt-bindings: brcm: Add reserved-dma-region for iPROC

On 15/03/18 12:03, Jitendra Bhivare wrote: On Thu, Mar 15, 2018 at 12:15 AM, Robin Murphy wrote: On 12/03/18 07:03, Jitendra Bhivare wrote: On Tue, Mar 6, 2018 at 5:12 PM, Robin Murphy wrote: On 06/03/18 04:59, Jitendra Bhivare wrote: With

Re: [RFC 3/5] dt-bindings: arm-smmu: Add reserved-msi-region

On 12/03/18 07:19, Jitendra Bhivare wrote: On Tue, Mar 6, 2018 at 5:17 PM, Robin Murphy wrote: On 06/03/18 04:59, Jitendra Bhivare wrote: iPROC SoC has a special device window to treat GICv3 ITS MSI. Ugh, really? After preferably printing out 100 copies of the SBSA,

Re: [PATCH 11/14] swiotlb: remove swiotlb_set_mem_attributes

On Thu, Mar 15, 2018 at 01:51:59PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 14, 2018 at 06:52:10PM +0100, Christoph Hellwig wrote: > > Now that set_memory_decrypted is always available we can just call it > > directly. > > > > Won't this break ARM build? And of course right after

Re: [PATCH 11/14] swiotlb: remove swiotlb_set_mem_attributes

On Wed, Mar 14, 2018 at 06:52:10PM +0100, Christoph Hellwig wrote: > Now that set_memory_decrypted is always available we can just call it > directly. > Won't this break ARM build? ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH 10/14] set_memory.h: provide set_memory_{en,de}crypted stubs

On Wed, Mar 14, 2018 at 06:52:09PM +0100, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig Reviewed-by: Konrad Rzeszutek Wilk Thank you! > --- > include/linux/set_memory.h | 12 > 1 file changed, 12 insertions(+) > > diff --git

Re: [PATCH 05/14] x86/amd_gart: look at coherent_dma_mask instead of GFP_DMA

On Wed, Mar 14, 2018 at 06:52:04PM +0100, Christoph Hellwig wrote: > We want to phase out looking at the magic GFP_DMA flag in the dma mapping > routines, so switch the gart driver to use the coherent_dma_mask instead, > which is used to select the GFP_DMA flag in the caller. > Reviewed-by:

[PATCH v5 6/7] vfio/type1: remove duplicate retrieval of reserved regions

As we now already have the reserved regions list, just pass that into vfio_iommu_has_sw_msi() fn. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git

[PATCH v5 4/7] vfio/type1: check dma map request is within a valid iova range

This checks and rejects any dma map request outside valid iova range. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/vfio/vfio_iommu_type1.c

[PATCH v5 2/7] vfio/type1: Check reserve region conflict and update iova list

This retrieves the reserved regions associated with dev group and checks for conflicts with any existing dma mappings. Also update the iova list excluding the reserved regions. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c | 90

[PATCH v5 7/7] iommu/dma: Move PCI window region reservation back into dma specific path.

This pretty much reverts commit 273df9635385 ("iommu/dma: Make PCI window reservation generic") by moving the PCI window region reservation back into the dma specific path so that these regions doesn't get exposed via the IOMMU API interface. With this change, the vfio interface will report only

[PATCH v5 5/7] vfio/type1: Add IOVA range capability support

This allows the user-space to retrieve the supported IOVA range(s), excluding any reserved regions. The implementation is based on capability chains, added to VFIO_IOMMU_GET_INFO ioctl. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c |

[PATCH v5 0/7] vfio/type1: Add support for valid iova list management

valid iova ranges using VFIO_IOMMU_GET_INFO ioctl capability chains. Any dma map request outside the valid iova range will be rejected. v4 --> v5 Rebased to next-20180315. -Incorporated the corner case bug fix suggested by Alex to patch #5. -Based on suggestions by Alex and Robin, added pa

[PATCH v5 3/7] vfio/type1: Update iova list on detach

Get a copy of iova list on _group_detach and try to update the list. On success replace the current one with the copy. Leave the list as it is if update fails. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c | 91

[PATCH v5 1/7] vfio/type1: Introduce iova list and add iommu aperture validity check

This introduces an iova list that is valid for dma mappings. Make sure the new iommu aperture window doesn't conflict with the current one or with any existing dma mappings during attach. Signed-off-by: Shameer Kolothum --- drivers/vfio/vfio_iommu_type1.c |

Re: [PATCH 07/14] iommu/amd_iommu: use dma_direct_{alloc,free}

On Wed, Mar 14, 2018 at 06:52:06PM +0100, Christoph Hellwig wrote: > This cleans up the code a lot by removing duplicate logic. > > Signed-off-by: Christoph Hellwig > --- > drivers/iommu/Kconfig | 1 + > drivers/iommu/amd_iommu.c | 68 >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:42:00PM +, Dmitry Safonov wrote: > But even with loop-limit we will need ratelimit each printk() *also*. > Otherwise loop-limit will be based on time spent printing, not on > anything else.. > The patch makes sense even with loop-limit in my opinion. Looks like I

Re: [PATCH 05/10] iommu/amd: remove the special case from get_irq_table()

On 2018-03-15 16:19:17 [+0100], Joerg Roedel wrote: > Okay, if the irq-layer does the needed locking, then we don't need > another lock here. There is the modify_irte_ga() path for the > virtualized irq routing into KVM guests, but there should be no KVM > guests running when setup the ioapic

Re: [PATCH 05/10] iommu/amd: remove the special case from get_irq_table()

On Thu, Mar 15, 2018 at 03:15:41PM +0100, Sebastian Andrzej Siewior wrote: > ->set_allocated() operates only on 0…31 and other could be used at the > same time. However 0…31 should be accessed by other user before they are > ready. > > irq_remapping_alloc() is that ->alloc() callback invoked via

Re: [PATCH] iommu/omap: Increase group ref in .device_group()

On Thu, Mar 01, 2018 at 07:22:08PM +0800, Jeffy Chen wrote: > Increase group refcounting in omap_iommu_device_group(). > > Signed-off-by: Jeffy Chen Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:34 +, Dmitry Safonov wrote: > On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > > So, you suggest to remove ratelimit at all? > > > Do we really need printk flood for each happened fault? > >

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 15:22 +0100, Joerg Roedel wrote: > On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > > So, you suggest to remove ratelimit at all? > > Do we really need printk flood for each happened fault? > > Imagine, you've hundreds of mappings and then PCI link flapped..

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Mar 15, 2018 at 02:13:03PM +, Dmitry Safonov wrote: > So, you suggest to remove ratelimit at all? > Do we really need printk flood for each happened fault? > Imagine, you've hundreds of mappings and then PCI link flapped.. > Wouldn't it be better to keep ratelimiting? > I don't mind,

Re: [PATCH 1/1] iommu/vt-d: Fix a potential memory leak

On Sat, Feb 24, 2018 at 01:42:27PM +0800, Lu Baolu wrote: > A memory block was allocated in intel_svm_bind_mm() but never freed > in a failure path. This patch fixes this by free it to avoid memory > leakage. > > Cc: Ashok Raj > Cc: Jacob Pan

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, 2018-03-15 at 14:46 +0100, Joerg Roedel wrote: > On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > > index accf58388bdb..6c4ea32ee6a9 100644 > > --- a/drivers/iommu/dmar.c > > +++ b/drivers/iommu/dmar.c > > @@

Re: [PATCH] iommu/rockchip: Perform a reset on shutdown

On Tue, Feb 20, 2018 at 08:25:04PM +, Marc Zyngier wrote: > Trying to do a kexec whilst the iommus are still on is proving to be > a challenging exercise. It is terribly unsafe, as we're reusing the > memory allocated for the page tables, leading to a likely crash. > > Let's implement a

Re: [PATCH v3 0/5] Add debugfs info for the AMD IOMMU

On Wed, Mar 14, 2018 at 06:04:44PM -0500, Gary R Hook wrote: > Gary R Hook (5): > iommu/amd - Add debugfs support > iommu/amd - Add a 'verbose' switch for IOMMU debugfs > iommu/amd - Add a README variable for the IOMMU debugfs > iommu/amd - Expose the active IOMMU device

Re: [PATCH 04/14] x86: use generic swiotlb_ops

On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 01:52:14PM +0100, Thomas Gleixner wrote: > > Yeah, I know that the standard defines it, but that doesn't mean it makes > > sense. At least not to me. > > It makes sense in that it logically is a boolean but we only want > to

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

On Thu, Feb 15, 2018 at 07:17:29PM +, Dmitry Safonov wrote: > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > index accf58388bdb..6c4ea32ee6a9 100644 > --- a/drivers/iommu/dmar.c > +++ b/drivers/iommu/dmar.c > @@ -1618,17 +1618,13 @@ irqreturn_t dmar_fault(int irq, void *dev_id) >

Re: [PATCH 03/14] x86: use dma-direct

On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 01:53:52PM +0100, Thomas Gleixner wrote: > > > > > The generic dma-direct implementation is now functionally equivalent > > > > > to > > > > > the x86 nommu dma_map implementation, so switch over to using it. > > > > > > > >

Re: [PATCH 03/14] x86: use dma-direct

On Thu, Mar 15, 2018 at 01:53:52PM +0100, Thomas Gleixner wrote: > > > > The generic dma-direct implementation is now functionally equivalent to > > > > the x86 nommu dma_map implementation, so switch over to using it. > > > > > > Can you please convert the various drivers first and then remove

Re: [PATCH 04/14] x86: use generic swiotlb_ops

On Thu, Mar 15, 2018 at 01:52:14PM +0100, Thomas Gleixner wrote: > Yeah, I know that the standard defines it, but that doesn't mean it makes > sense. At least not to me. It makes sense in that it logically is a boolean but we only want to allocate 1 bit for it, unlike the normal ABI allocations

Re: [PATCH v7 0/5] Add Intel IOMMU debugfs support

On Thu, Feb 15, 2018 at 08:38:11AM -0800, Jacob Pan wrote: > Just wondering if your concern is on the implementation or the debugfs > idea in general. Perhaps have some common IOMMU debugfs? My concern mainly is that we add interfaces which reveal potentially security relevant information to

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On 15/03/18 07:58, Christoph Hellwig wrote: On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote: Looking back I don't really understand why we even indirect the "classic" per-device dma_declare_coherent_memory use case through the DMA API. It certainly makes sense for devices which

Re: [PATCH 05/10] iommu/amd: remove the special case from get_irq_table()

On Thu, Mar 15, 2018 at 02:01:53PM +0100, Sebastian Andrzej Siewior wrote: > On 2018-03-15 13:53:42 [+0100], Joerg Roedel wrote: > > On Fri, Feb 23, 2018 at 11:27:31PM +0100, Sebastian Andrzej Siewior wrote: > > > @@ -4103,10 +4093,26 @@ static int irq_remapping_alloc(struct irq_domain > > >

Re: [PATCH 05/10] iommu/amd: remove the special case from get_irq_table()

On 2018-03-15 13:53:42 [+0100], Joerg Roedel wrote: > On Fri, Feb 23, 2018 at 11:27:31PM +0100, Sebastian Andrzej Siewior wrote: > > @@ -4103,10 +4093,26 @@ static int irq_remapping_alloc(struct irq_domain > > *domain, unsigned int virq, > > return ret; > > > > if (info->type ==

Re: iommu/amd: lock splitting & GFP_KERNEL allocation

Hi Sebastian, On Fri, Feb 23, 2018 at 11:27:26PM +0100, Sebastian Andrzej Siewior wrote: > I have no idea why but suddenly my A10 box complained loudly about > locking and memory allocations within the iommu code under RT. Looking > at the code it has been like this for a longer time so the iommu

Re: [PATCH 08/10] iommu/amd: drop the lock while allocating new irq remap table

On Fri, Feb 23, 2018 at 11:27:34PM +0100, Sebastian Andrzej Siewior wrote: > The irq_remap_table is allocated while the iommu_table_lock is held with > interrupts disabled. While this works it makes RT scream very loudly. > >From looking at the call sites, all callers are in the early device >

Re: [PATCH 04/10] iommu/amd: split irq_lookup_table out of the amd_iommu_devtable_lock

On Fri, Feb 23, 2018 at 11:27:30PM +0100, Sebastian Andrzej Siewior wrote: > The function get_irq_table() reads/writes irq_lookup_table while holding > the amd_iommu_devtable_lock. It also modifies > amd_iommu_dev_table[].data[2]. > set_dte_entry() is using amd_iommu_dev_table[].data[0|1] (under

Re: [PATCH 03/14] x86: use dma-direct

On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 09:56:13AM +0100, Thomas Gleixner wrote: > > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > > > > The generic dma-direct implementation is now functionally equivalent to > > > the x86 nommu dma_map implementation, so

Re: [PATCH 05/10] iommu/amd: remove the special case from get_irq_table()

On Fri, Feb 23, 2018 at 11:27:31PM +0100, Sebastian Andrzej Siewior wrote: > @@ -4103,10 +4093,26 @@ static int irq_remapping_alloc(struct irq_domain > *domain, unsigned int virq, > return ret; > > if (info->type == X86_IRQ_ALLOC_TYPE_IOAPIC) { > - if

Re: [PATCH 04/14] x86: use generic swiotlb_ops

On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 10:00:57AM +0100, Thomas Gleixner wrote: > > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > > #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > > > void *iommu; /* hook for IOMMU specific extension */ > > >

Re: [PATCH v4] iommu/amd: Add support for fast IOTLB flushing

Hi Suravee, On Mon, Mar 05, 2018 at 08:08:21AM +0700, Suravee Suthikulpanit wrote: > Ping.. > > Joerg, when you get a chance, would you please let me know if you have any > other concerns for this v4. Sorry for the long delay. The patch is fine, I applied it to the iommu-tree. Thanks,

Re: [RFC 2/5] dt-bindings: brcm: Add reserved-dma-region for iPROC

On Thu, Mar 15, 2018 at 12:15 AM, Robin Murphy wrote: > On 12/03/18 07:03, Jitendra Bhivare wrote: >> >> On Tue, Mar 6, 2018 at 5:12 PM, Robin Murphy wrote: >>> >>> On 06/03/18 04:59, Jitendra Bhivare wrote: With SoC wide DMA mask of

Re: [PATCH 04/14] x86: use generic swiotlb_ops

On Thu, Mar 15, 2018 at 10:00:57AM +0100, Thomas Gleixner wrote: > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > > void *iommu; /* hook for IOMMU specific extension */ > > #endif > > +#ifdef CONFIG_STA2X11 > > + bool

Re: [PATCH 03/14] x86: use dma-direct

On Thu, Mar 15, 2018 at 09:56:13AM +0100, Thomas Gleixner wrote: > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > > The generic dma-direct implementation is now functionally equivalent to > > the x86 nommu dma_map implementation, so switch over to using it. > > Can you please convert the

Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On 15/03/18 08:57, Vivek Gautam wrote: Hi Robin, On Wed, Mar 14, 2018 at 11:20 PM, Robin Murphy wrote: On 13/03/18 08:55, Vivek Gautam wrote: From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu

Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On 15/03/18 06:18, Tomasz Figa wrote: On Thu, Mar 15, 2018 at 2:50 AM, Robin Murphy wrote: On 13/03/18 08:55, Vivek Gautam wrote: From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime

Re: [PATCH 04/14] x86: use generic swiotlb_ops

On Wed, 14 Mar 2018, Christoph Hellwig wrote: > #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > void *iommu; /* hook for IOMMU specific extension */ > #endif > +#ifdef CONFIG_STA2X11 > + bool is_sta2x11 : 1; Huch? Please use either bool or an unsigned int based

Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

Hi Robin, On Wed, Mar 14, 2018 at 11:20 PM, Robin Murphy wrote: > On 13/03/18 08:55, Vivek Gautam wrote: >> >> From: Sricharan R >> >> Finally add the device link between the master device and >> smmu, so that the smmu gets runtime

Re: [PATCH 03/14] x86: use dma-direct

On Wed, 14 Mar 2018, Christoph Hellwig wrote: > The generic dma-direct implementation is now functionally equivalent to > the x86 nommu dma_map implementation, so switch over to using it. Can you please convert the various drivers first and then remove the unused code? > Note that the various

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote: >> Looking back I don't really understand why we even indirect the "classic" >> per-device dma_declare_coherent_memory use case through the DMA API. > > It certainly makes sense for devices which can exist in both shared-memory > and

Re: [PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On Thu, Mar 15, 2018 at 2:46 AM, Robin Murphy wrote: > On 13/03/18 08:55, Vivek Gautam wrote: >> >> From: Sricharan R >> >> The smmu device probe/remove and add/remove master device callbacks >> gets called when the smmu is not linked to its

Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On Thu, Mar 15, 2018 at 2:50 AM, Robin Murphy wrote: > On 13/03/18 08:55, Vivek Gautam wrote: >> >> From: Sricharan R >> >> Finally add the device link between the master device and >> smmu, so that the smmu gets runtime enabled/disabled only when