1. 15 Oct, 2019 3 commits
    • Tom Murphy's avatar
      iommu/dma-iommu: Handle deferred devices · 795bbbb9
      Tom Murphy authored
      Handle devices which defer their attach to the iommu in the dma-iommu api
      Signed-off-by: default avatarTom Murphy <murphyt7@tcd.ie>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      795bbbb9
    • Tom Murphy's avatar
      iommu: Add gfp parameter to iommu_ops::map · 781ca2de
      Tom Murphy authored
      Add a gfp_t parameter to the iommu_ops::map function.
      Remove the needless locking in the AMD iommu driver.
      
      The iommu_ops::map function (or the iommu_map function which calls it)
      was always supposed to be sleepable (according to Joerg's comment in
      this thread: https://lore.kernel.org/patchwork/patch/977520/ ) and so
      should probably have had a "might_sleep()" since it was written. However
      currently the dma-iommu api can call iommu_map in an atomic context,
      which it shouldn't do. This doesn't cause any problems because any iommu
      driver which uses the dma-iommu api uses gfp_atomic in it's
      iommu_ops::map function. But doing this wastes the memory allocators
      atomic pools.
      Signed-off-by: default avatarTom Murphy <murphyt7@tcd.ie>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      781ca2de
    • Tom Murphy's avatar
      iommu/amd: Remove unnecessary locking from AMD iommu driver · 37ec8eb8
      Tom Murphy authored
      With or without locking it doesn't make sense for two writers to be
      writing to the same IOVA range at the same time. Even with locking we
      still have a race condition, whoever gets the lock first, so we still
      can't be sure what the result will be. With locking the result will be
      more sane, it will be correct for the last writer, but still useless
      because we can't be sure which writer will get the lock last. It's a
      fundamentally broken design to have two writers writing to the same
      IOVA range at the same time.
      
      So we can remove the locking and work on the assumption that no two
      writers will be writing to the same IOVA range at the same time.
      
      The only exception is when we have to allocate a middle page in the page
      tables, the middle page can cover more than just the IOVA range a writer
      has been allocated. However this isn't an issue in the AMD driver
      because it can atomically allocate middle pages using "cmpxchg64()".
      Signed-off-by: default avatarTom Murphy <murphyt7@tcd.ie>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      37ec8eb8
  2. 13 Oct, 2019 16 commits
  3. 12 Oct, 2019 21 commits