1. 02 Jun, 2015 1 commit
  2. 02 Apr, 2015 9 commits
  3. 31 Mar, 2015 1 commit
  4. 04 Feb, 2015 2 commits
  5. 15 Jan, 2015 1 commit
  6. 16 Dec, 2014 1 commit
  7. 14 Nov, 2014 1 commit
    • Will Deacon's avatar
      iommu/amd: remove compiler warning due to IOMMU_CAP_NOEXEC · cfdeec22
      Will Deacon authored
      
      
      Some versions of GCC get unduly upset when confronted with a switch
      that doesn't explicitly handle all cases of an enum, despite having an
      implicit default case following the actualy switch statement:
      
         drivers/iommu/amd_iommu.c: In function 'amd_iommu_capable':
      >> drivers/iommu/amd_iommu.c:3409:2: warning: enumeration value 'IOMMU_CAP_NOEXEC' not handled in switch [-Wswitch]
           switch (cap) {
      
      This patch adds a case for IOMMU_CAP_NOEXEC to the amd IOMMU driver to
      remove this warning.
      
      Cc: Joerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      cfdeec22
  8. 04 Nov, 2014 1 commit
    • Olav Haugan's avatar
      iommu: Add iommu_map_sg() function · 315786eb
      Olav Haugan authored
      
      
      Mapping and unmapping are more often than not in the critical path.
      map_sg allows IOMMU driver implementations to optimize the process
      of mapping buffers into the IOMMU page tables.
      
      Instead of mapping a buffer one page at a time and requiring potentially
      expensive TLB operations for each page, this function allows the driver
      to map all pages in one go and defer TLB maintenance until after all
      pages have been mapped.
      
      Additionally, the mapping operation would be faster in general since
      clients does not have to keep calling map API over and over again for
      each physically contiguous chunk of memory that needs to be mapped to a
      virtually contiguous region.
      Signed-off-by: default avatarOlav Haugan <ohaugan@codeaurora.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      315786eb
  9. 25 Sep, 2014 4 commits
  10. 26 Aug, 2014 4 commits
  11. 18 Aug, 2014 1 commit
  12. 07 Jul, 2014 1 commit
  13. 04 Jul, 2014 3 commits
    • Alex Williamson's avatar
      iommu/amd: Add sysfs support · 066f2e98
      Alex Williamson authored
      
      
      AMD-Vi support for IOMMU sysfs.  This allows us to associate devices
      with a specific IOMMU device and examine the capabilities and features
      of that IOMMU.  The AMD IOMMU is hosted on and actual PCI device, so
      we make that device the parent for the IOMMU class device.  This
      initial implementaiton exposes only the capability header and extended
      features register for the IOMMU.
      
      # find /sys | grep ivhd
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:00.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:02.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:04.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:09.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:11.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:12.0
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:12.2
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/devices/0000:00:13.0
      ...
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/power
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/power/control
      ...
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/device
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/subsystem
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu/cap
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/amd-iommu/features
      /sys/devices/pci0000:00/0000:00:00.2/iommu/ivhd0/uevent
      /sys/class/iommu/ivhd0
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      066f2e98
    • Alex Williamson's avatar
      iommu/amd: Use iommu_group_get_for_dev() · 65d5352f
      Alex Williamson authored
      
      
      The common iommu_group_get_for_dev() allows us to greatly simplify
      our group lookup for a new device.  Also, since we insert IVRS
      aliases into the PCI DMA alias quirks, we should alway come up with
      the same results as the existing code.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      65d5352f
    • Alex Williamson's avatar
      iommu/amd: Update to use PCI DMA aliases · c1931090
      Alex Williamson authored
      
      
      AMD-Vi already has a concept of an alias provided via the IVRS table.
      Now that PCI-core also understands aliases, we need to incorporate
      both aspects when programming the IOMMU.  IVRS is generally quite
      reliable, so we continue to prefer it when an alias is present.  For
      cases where we have an IVRS alias that does not match the PCI alias
      or where PCI does not report an alias, report the mismatch to allow
      us to collect more quirks and dynamically incorporate the alias into
      the device alias quirks where possible.
      
      This should allow AMD-Vi to work with devices like Marvell and Ricoh
      with DMA function alias quirks unknown to the BIOS.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      c1931090
  14. 30 May, 2014 1 commit
  15. 26 May, 2014 1 commit
  16. 13 May, 2014 1 commit
  17. 24 Mar, 2014 1 commit
  18. 04 Mar, 2014 1 commit
  19. 07 Jan, 2014 1 commit
  20. 14 Aug, 2013 1 commit
  21. 23 Jun, 2013 1 commit
    • Alex Williamson's avatar
      iommu/amd: Only unmap large pages from the first pte · 60d0ca3c
      Alex Williamson authored
      
      
      If we use a large mapping, the expectation is that only unmaps from
      the first pte in the superpage are supported.  Unmaps from offsets
      into the superpage should fail (ie. return zero sized unmap).  In the
      current code, unmapping from an offset clears the size of the full
      mapping starting from an offset.  For instance, if we map a 16k
      physically contiguous range at IOVA 0x0 with a large page, then
      attempt to unmap 4k at offset 12k, 4 ptes are cleared (12k - 28k) and
      the unmap returns 16k unmapped.  This potentially incorrectly clears
      valid mappings and confuses drivers like VFIO that use the unmap size
      to release pinned pages.
      
      Fix by refusing to unmap from offsets into the page.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      60d0ca3c
  22. 20 Jun, 2013 2 commits