Re: [PATCH 0/4] ipmmu-vmsa cleanup

On Fri, Oct 13, 2017 at 8:23 PM, Robin Murphy wrote: > Arnd reports a build warning[1] thanks to me missing ipmmu-vmsa's second > set of ops when converting io-pgtable-arm users to the new iommu_iotlb_* > callbacks. Rather than just treat the symptom with a point fix, this >

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote: > IOMMU drivers can use this to implement their .get_resv_regions callback > for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region). > > Signed-off-by: Shameer Kolothum > --- >

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote: > The HiSilicon erratum 161010801 describes the limitation of > HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings > for MSI transactions. > > PCIe controller on these platforms has to differentiate the MSI > payload

Re: [RFCv2 PATCH 12/36] dt-bindings: document stall and PASID properties for IOMMU masters

On Fri, Oct 06, 2017 at 02:31:39PM +0100, Jean-Philippe Brucker wrote: > On ARM systems, some platform devices behind an IOMMU may support stall > and PASID features. Stall is the ability to recover from page faults and > PASID offers multiple process address spaces to the device. Together they >

Re: [PATCH v2 1/1] iommu/arm-smmu: Defer TLB flush in case of unmap op

On Wed, Sep 06, 2017 at 11:07:35AM +0530, Vivek Gautam wrote: > We don't want to touch the TLB when smmu is suspended, so > defer the TLB maintenance until smmu is resumed. > On resume, we issue arm_smmu_device_reset() to restore the > configuration and flush the TLBs. > > Signed-off-by: Vivek

Re: [PATCH v2 0/4] SMMUv3 CMD_SYNC optimisation

Hi Robin, On Thu, Aug 31, 2017 at 02:44:24PM +0100, Robin Murphy wrote: > 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

Re: [PATCH v2 4/4] iommu/arm-smmu-v3: Poll for CMD_SYNC outside cmdq lock

Hi Robin, Some of my comments on patch 3 are addressed here, but I'm really struggling to convince myself that this algorithm is correct. My preference would be to leave the code as it is for SMMUs that don't implement MSIs, but comments below anyway because it's an interesting idea. On Thu, Aug

Re: [PATCH v2 3/4] iommu/arm-smmu-v3: Use CMD_SYNC completion MSI

Hi Robin, This mostly looks good. Just a few comments below. On Thu, Aug 31, 2017 at 02:44:27PM +0100, Robin Murphy wrote: > 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.

[PATCH 4/4] iommu/ipmmu-vmsa: Unify ipmmu_ops

The remaining difference between the ARM-specific and iommu-dma ops is in the {add,remove}_device implementations, but even those have some overlap and duplication. By stubbing out the few arm_iommu_*() calls, we can get rid of the rest of the inline #ifdeffery to both simplify the code and

[PATCH 2/4] iommu/ipmmu-vmsa: Simplify group allocation

We go through quite the merry dance in order to find masters behind the same IPMMU instance, so that we can ensure they are grouped together. None of which is really necessary, since the master's private data already points to the particular IPMMU it is associated with, and that IPMMU instance

[PATCH 3/4] iommu/ipmmu-vmsa: Clean up struct ipmmu_vmsa_iommu_priv

Now that the IPMMU instance pointer is the only thing remaining in the private data structure, we no longer need the extra level of indirection and can simply stash that directlty in the fwspec. Signed-off-by: Robin Murphy --- drivers/iommu/ipmmu-vmsa.c | 36

[PATCH 1/4] iommu/ipmmu-vmsa: Unify domain alloc/free

We have two implementations for ipmmu_ops->alloc depending on CONFIG_IOMMU_DMA, the difference being whether they accept the IOMMU_DOMAIN_DMA type or not. However, iommu_dma_get_cookie() is guaranteed to return an error when !CONFIG_IOMMU_DMA, so if ipmmu_domain_alloc_dma() was actually checking

[PATCH 0/4] ipmmu-vmsa cleanup

Arnd reports a build warning[1] thanks to me missing ipmmu-vmsa's second set of ops when converting io-pgtable-arm users to the new iommu_iotlb_* callbacks. Rather than just treat the symptom with a point fix, this seemed like a good excuse to clean up the messy #ifdeffery and duplication in the

Re: [PATCH 4/4] vfio/type1: Gather TLB-syncs and pages to unpin

On Fri, 13 Oct 2017 16:40:13 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > After every unmap VFIO unpins the pages that where mapped by > the IOMMU. This requires an IOTLB flush after every unmap > and puts a high load on the IOMMU hardware and the device

[git pull] IOMMU Fixes for Linux v4.14-rc4

Hi Linus, The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v4.14-rc4 for you to fetch changes up to

[PATCH 1/4] iommu/amd: Finish TLB flush in amd_iommu_unmap()

From: Joerg Roedel The function only sends the flush command to the IOMMU(s), but does not wait for its completion when it returns. Fix that. Fixes: 601367d76bd1 ('x86/amd-iommu: Remove iommu_flush_domain function') Cc: sta...@vger.kernel.org # >= 2.6.33 Signed-off-by: Joerg

[PATCH 2/4] iommu/amd: Implement IOMMU-API TLB flush interface

From: Joerg Roedel Make use of the new IOTLB flush-interface in the IOMMU-API. We don't implement the iotlb_range_add() call-back for now, as this will put too many pressure on the command buffer. Instead, we do a full TLB flush in the iotlb_sync() call-back. Signed-off-by:

[PATCH 3/4] vfio/type1: Make use of iommu_unmap_fast()

From: Joerg Roedel Switch from using iommu_unmap to iommu_unmap_fast() and add the necessary calls the the IOTLB invalidation routines. Signed-off-by: Joerg Roedel --- drivers/vfio/vfio_iommu_type1.c | 24 ++-- 1 file changed, 18

[PATCH 4/4] vfio/type1: Gather TLB-syncs and pages to unpin

From: Joerg Roedel After every unmap VFIO unpins the pages that where mapped by the IOMMU. This requires an IOTLB flush after every unmap and puts a high load on the IOMMU hardware and the device TLBs. Gather up to 32 ranges to flush and unpin and do the IOTLB flush once for

Re: [PATCH] dt-bindings: iommu: ipmmu-vmsa: Use generic node name

On Wed, Oct 04, 2017 at 02:33:08PM +0200, Geert Uytterhoeven wrote: > Use the preferred generic node name in the example. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 2 +- > 1 file changed, 1

Re: [PATCH v2 1/2] iommu/tegra: gart: Optionally check for overwriting of page mappings

On 13.10.2017 11:38, Joerg Roedel wrote: > On Thu, Oct 12, 2017 at 05:27:26PM +0300, Dmitry Osipenko wrote: >> I'm not talking about any specific bug, but in general if allocator re-maps >> already mapped region or unmaps the wrong-and-used region. I had those >> bug-cases >> during of

Re: [PATCH] xhci: Set DMA parameters appropriately

Hi Marek, On 13/10/17 09:15, Marek Szyprowski wrote: > Hi Robin, > > On 2017-10-11 15:56, Robin Murphy wrote: >> xHCI requires that data buffers do not cross 64KB boundaries (and are >> thus at most 64KB long as well) - whilst xhci_queue_{bulk,isoc}_tx() >> already split their input buffers into

Re: [PATCH v2 1/2] iommu/tegra: gart: Optionally check for overwriting of page mappings

On Thu, Oct 12, 2017 at 05:27:26PM +0300, Dmitry Osipenko wrote: > I'm not talking about any specific bug, but in general if allocator re-maps > already mapped region or unmaps the wrong-and-used region. I had those > bug-cases > during of development of the 'scattered' graphics allocations for

Re: [PATCH] xhci: Set DMA parameters appropriately

Hi Robin, On 2017-10-11 15:56, Robin Murphy wrote: xHCI requires that data buffers do not cross 64KB boundaries (and are thus at most 64KB long as well) - whilst xhci_queue_{bulk,isoc}_tx() already split their input buffers into individual TRBs as necessary, it's still a good idea to advertise