1. 02 4月, 2015 9 次提交
  2. 31 3月, 2015 1 次提交
  3. 04 2月, 2015 2 次提交
  4. 15 1月, 2015 1 次提交
  5. 16 12月, 2014 1 次提交
  6. 14 11月, 2014 1 次提交
    • W
      iommu/amd: remove compiler warning due to IOMMU_CAP_NOEXEC · cfdeec22
      Will Deacon 提交于
      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: NWill Deacon <will.deacon@arm.com>
      cfdeec22
  7. 04 11月, 2014 1 次提交
    • O
      iommu: Add iommu_map_sg() function · 315786eb
      Olav Haugan 提交于
      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: NOlav Haugan <ohaugan@codeaurora.org>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      315786eb
  8. 26 9月, 2014 1 次提交
    • Y
      iommu/irq_remapping: Fix the regression of hpet irq remapping · 5fc24d8c
      Yijing Wang 提交于
      Commit 71054d88 ("x86, hpet: Introduce x86_msi_ops.setup_hpet_msi")
      introduced x86_msi_ops.setup_hpet_msi to setup hpet MSI irq
      when irq remapping enabled. This caused a regression of
      hpet MSI irq remapping.
      
      Original code flow before commit 71054d88:
      hpet_setup_msi_irq()
      	arch_setup_hpet_msi()
      		setup_hpet_msi_remapped()
      			remap_ops->setup_hpet_msi()
      				alloc_irte()
      		msi_compose_msg()
      		hpet_msi_write()
      		...
      
      Current code flow after commit 71054d88:
      hpet_setup_msi_irq()
      	x86_msi.setup_hpet_msi()
      		setup_hpet_msi_remapped()
      			intel_setup_hpet_msi()
      				alloc_irte()
      
      Currently, we only call alloc_irte() for hpet MSI, but
      do not composed and wrote its msg...
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5fc24d8c
  9. 25 9月, 2014 3 次提交
  10. 26 8月, 2014 4 次提交
  11. 18 8月, 2014 1 次提交
  12. 07 7月, 2014 1 次提交
  13. 04 7月, 2014 3 次提交
    • A
      iommu/amd: Add sysfs support · 066f2e98
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      066f2e98
    • A
      iommu/amd: Use iommu_group_get_for_dev() · 65d5352f
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      65d5352f
    • A
      iommu/amd: Update to use PCI DMA aliases · c1931090
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      c1931090
  14. 31 5月, 2014 1 次提交
  15. 26 5月, 2014 1 次提交
  16. 13 5月, 2014 1 次提交
  17. 24 3月, 2014 1 次提交
  18. 04 3月, 2014 1 次提交
  19. 07 1月, 2014 1 次提交
  20. 15 8月, 2013 1 次提交
  21. 23 6月, 2013 1 次提交
    • A
      iommu/amd: Only unmap large pages from the first pte · 60d0ca3c
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      60d0ca3c
  22. 21 6月, 2013 1 次提交
  23. 20 6月, 2013 1 次提交
    • A
      iommu/{vt-d,amd}: Remove multifunction assumption around grouping · c14d2690
      Alex Williamson 提交于
      If a device is multifunction and does not have ACS enabled then we
      assume that the entire package lacks ACS and use function 0 as the
      base of the group.  The PCIe spec however states that components are
      permitted to implement ACS on some, none, or all of their applicable
      functions.  It's therefore conceivable that function 0 may be fully
      independent and support ACS while other functions do not.  Instead
      use the lowest function of the slot that does not have ACS enabled
      as the base of the group.  This may be the current device, which is
      intentional.  So long as we use a consistent algorithm, all the
      non-ACS functions will be grouped together and ACS functions will
      get separate groups.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      c14d2690
  24. 23 4月, 2013 1 次提交