1. 26 8月, 2014 1 次提交
  2. 18 8月, 2014 1 次提交
  3. 07 7月, 2014 1 次提交
  4. 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
  5. 31 5月, 2014 1 次提交
  6. 26 5月, 2014 1 次提交
  7. 13 5月, 2014 1 次提交
  8. 24 3月, 2014 1 次提交
  9. 04 3月, 2014 1 次提交
  10. 07 1月, 2014 1 次提交
  11. 15 8月, 2013 1 次提交
  12. 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
  13. 21 6月, 2013 1 次提交
  14. 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
  15. 23 4月, 2013 2 次提交
    • V
      iommu: Move swap_pci_ref function to drivers/iommu/pci.h. · 61e015ac
      Varun Sethi 提交于
      The swap_pci_ref function is used by the IOMMU API code for
      swapping pci device pointers, while determining the iommu
      group for the device.
      Currently this function was being implemented for different
      IOMMU drivers.  This patch moves the function to a new file,
      drivers/iommu/pci.h so that the implementation can be
      shared across various IOMMU drivers.
      Signed-off-by: NVarun Sethi <Varun.Sethi@freescale.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      61e015ac
    • S
      iommu/AMD: Per-thread IOMMU Interrupt Handling · 3f398bc7
      Suravee Suthikulpanit 提交于
      In the current interrupt handling scheme, there are as many threads as
      the number of IOMMUs. Each thread is created and assigned to an IOMMU at
      the time of registering interrupt handlers (request_threaded_irq).
      When an IOMMU HW generates an interrupt, the irq handler (top half) wakes up
      the corresponding thread to process event and PPR logs of all IOMMUs
      starting from the 1st IOMMU.
      
      In the system with multiple IOMMU,this handling scheme complicates the
      synchronization of the IOMMU data structures and status registers as
      there could be multiple threads competing for the same IOMMU while
      the other IOMMU could be left unhandled.
      
      To simplify, this patch is proposing a different interrupt handling scheme
      by having each thread only managing interrupts of the corresponding IOMMU.
      This can be achieved by passing the struct amd_iommu when registering the
      interrupt handlers. This structure is unique for each IOMMU and can be used
      by the bottom half thread to identify the IOMMU to be handled instead
      of calling for_each_iommu.  Besides this also eliminate the needs to lock
      the IOMMU for processing event and PPR logs.
      Signed-off-by: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      3f398bc7
  16. 20 4月, 2013 1 次提交
  17. 18 4月, 2013 3 次提交
  18. 03 4月, 2013 1 次提交
  19. 02 4月, 2013 1 次提交
  20. 27 3月, 2013 3 次提交
  21. 13 2月, 2013 1 次提交
  22. 28 1月, 2013 1 次提交
  23. 02 12月, 2012 2 次提交
  24. 24 10月, 2012 5 次提交
  25. 02 10月, 2012 2 次提交
  26. 28 9月, 2012 2 次提交