1. 07 8月, 2012 1 次提交
  2. 19 7月, 2012 1 次提交
  3. 17 7月, 2012 3 次提交
  4. 11 7月, 2012 1 次提交
  5. 02 7月, 2012 1 次提交
  6. 25 6月, 2012 4 次提交
    • A
      amd_iommu: Make use of DMA quirks and ACS checks in IOMMU groups · 664b6003
      Alex Williamson 提交于
      Work around broken devices and adhere to ACS support when determining
      IOMMU grouping.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      664b6003
    • A
      amd_iommu: Support IOMMU groups · 9dcd6130
      Alex Williamson 提交于
      Add IOMMU group support to AMD-Vi device init and uninit code.
      Existing notifiers make sure this gets called for each device.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      9dcd6130
    • A
      iommu: IOMMU Groups · d72e31c9
      Alex Williamson 提交于
      IOMMU device groups are currently a rather vague associative notion
      with assembly required by the user or user level driver provider to
      do anything useful.  This patch intends to grow the IOMMU group concept
      into something a bit more consumable.
      
      To do this, we first create an object representing the group, struct
      iommu_group.  This structure is allocated (iommu_group_alloc) and
      filled (iommu_group_add_device) by the iommu driver.  The iommu driver
      is free to add devices to the group using it's own set of policies.
      This allows inclusion of devices based on physical hardware or topology
      limitations of the platform, as well as soft requirements, such as
      multi-function trust levels or peer-to-peer protection of the
      interconnects.  Each device may only belong to a single iommu group,
      which is linked from struct device.iommu_group.  IOMMU groups are
      maintained using kobject reference counting, allowing for automatic
      removal of empty, unreferenced groups.  It is the responsibility of
      the iommu driver to remove devices from the group
      (iommu_group_remove_device).
      
      IOMMU groups also include a userspace representation in sysfs under
      /sys/kernel/iommu_groups.  When allocated, each group is given a
      dynamically assign ID (int).  The ID is managed by the core IOMMU group
      code to support multiple heterogeneous iommu drivers, which could
      potentially collide in group naming/numbering.  This also keeps group
      IDs to small, easily managed values.  A directory is created under
      /sys/kernel/iommu_groups for each group.  A further subdirectory named
      "devices" contains links to each device within the group.  The iommu_group
      file in the device's sysfs directory, which formerly contained a group
      number when read, is now a link to the iommu group.  Example:
      
      $ ls -l /sys/kernel/iommu_groups/26/devices/
      total 0
      lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:00:1e.0 ->
      		../../../../devices/pci0000:00/0000:00:1e.0
      lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.0 ->
      		../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.0
      lrwxrwxrwx. 1 root root 0 Apr 17 12:57 0000:06:0d.1 ->
      		../../../../devices/pci0000:00/0000:00:1e.0/0000:06:0d.1
      
      $ ls -l  /sys/kernel/iommu_groups/26/devices/*/iommu_group
      [truncating perms/owner/timestamp]
      /sys/kernel/iommu_groups/26/devices/0000:00:1e.0/iommu_group ->
      					../../../kernel/iommu_groups/26
      /sys/kernel/iommu_groups/26/devices/0000:06:0d.0/iommu_group ->
      					../../../../kernel/iommu_groups/26
      /sys/kernel/iommu_groups/26/devices/0000:06:0d.1/iommu_group ->
      					../../../../kernel/iommu_groups/26
      
      Groups also include several exported functions for use by user level
      driver providers, for example VFIO.  These include:
      
      iommu_group_get(): Acquires a reference to a group from a device
      iommu_group_put(): Releases reference
      iommu_group_for_each_dev(): Iterates over group devices using callback
      iommu_group_[un]register_notifier(): Allows notification of device add
              and remove operations relevant to the group
      iommu_group_id(): Return the group number
      
      This patch also extends the IOMMU API to allow attaching groups to
      domains.  This is currently a simple wrapper for iterating through
      devices within a group, but it's expected that the IOMMU API may
      eventually make groups a more integral part of domains.
      
      Groups intentionally do not try to manage group ownership.  A user
      level driver provider must independently acquire ownership for each
      device within a group before making use of the group as a whole.
      This may change in the future if group usage becomes more pervasive
      across both DMA and IOMMU ops.
      
      Groups intentionally do not provide a mechanism for driver locking
      or otherwise manipulating driver matching/probing of devices within
      the group.  Such interfaces are generic to devices and beyond the
      scope of IOMMU groups.  If implemented, user level providers have
      ready access via iommu_group_for_each_dev and group notifiers.
      
      iommu_device_group() is removed here as it has no users.  The
      replacement is:
      
      	group = iommu_group_get(dev);
      	id = iommu_group_id(group);
      	iommu_group_put(group);
      
      AMD-Vi & Intel VT-d support re-added in following patches.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      d72e31c9
    • J
      iommu/amd: Initialize dma_ops for hotplug and sriov devices · ac1534a5
      Joerg Roedel 提交于
      When a device is added to the system at runtime the AMD
      IOMMU driver initializes the necessary data structures to
      handle translation for it. But it forgets to change the
      per-device dma_ops to point to the AMD IOMMU driver. So
      mapping actually never happens and all DMA accesses end in
      an IO_PAGE_FAULT. Fix this.
      Reported-by: NStefan Assmann <sassmann@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      ac1534a5
  7. 04 6月, 2012 1 次提交
    • J
      iommu/amd: Fix deadlock in ppr-handling error path · eee53537
      Joerg Roedel 提交于
      In the error path of the ppr_notifer it can happen that the
      iommu->lock is taken recursivly. This patch fixes the
      problem by releasing the iommu->lock before any notifier is
      invoked. This also requires to move the erratum workaround
      for the ppr-log (interrupt may be faster than data in the log)
      one function up.
      
      Cc: stable@vger.kernel.org # v3.3, v3.4
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      eee53537
  8. 12 4月, 2012 2 次提交
  9. 28 3月, 2012 1 次提交
  10. 19 3月, 2012 1 次提交
    • S
      x86: Fix section warnings · 943bc7e1
      Steffen Persvold 提交于
      Fix the following section warnings :
      
      WARNING: vmlinux.o(.text+0x49dbc): Section mismatch in reference
      from the function acpi_map_cpu2node() to the variable
      .cpuinit.data:__apicid_to_node The function acpi_map_cpu2node()
      references the variable __cpuinitdata __apicid_to_node. This is
      often because acpi_map_cpu2node lacks a __cpuinitdata
      annotation or the annotation of __apicid_to_node is wrong.
      
      WARNING: vmlinux.o(.text+0x49dc1): Section mismatch in reference
      from the function acpi_map_cpu2node() to the function
      .cpuinit.text:numa_set_node() The function acpi_map_cpu2node()
      references the function __cpuinit numa_set_node(). This is often
      because acpi_map_cpu2node lacks a __cpuinit  annotation or the
      annotation of numa_set_node is wrong.
      
      WARNING: vmlinux.o(.text+0x526e77): Section mismatch in
      reference from the function prealloc_protection_domains() to the
      function .init.text:alloc_passthrough_domain() The function
      prealloc_protection_domains() references the function __init
      alloc_passthrough_domain(). This is often because
      prealloc_protection_domains lacks a __init  annotation or the annotation of alloc_passthrough_domain is wrong.
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Link: http://lkml.kernel.org/r/1331810188-24785-1-git-send-email-sp@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      943bc7e1
  11. 15 3月, 2012 1 次提交
    • S
      iommu/amd: Fix section warning for prealloc_protection_domains · cebd5fa4
      Steffen Persvold 提交于
      Fix the following section warning in drivers/iommu/amd_iommu.c :
      
      WARNING: vmlinux.o(.text+0x526e77): Section mismatch in reference from the function prealloc_protection_domains() to the function .init.text:alloc_passthrough_domain()
      The function prealloc_protection_domains() references
      the function __init alloc_passthrough_domain().
      This is often because prealloc_protection_domains lacks a __init
      annotation or the annotation of alloc_passthrough_domain is wrong.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      cebd5fa4
  12. 23 1月, 2012 1 次提交
    • J
      iommu/amd: Work around broken IVRS tables · af1be049
      Joerg Roedel 提交于
      On some systems the IVRS table does not contain all PCI
      devices present in the system. In case a device not present
      in the IVRS table is translated by the IOMMU no DMA is
      possible from that device by default.
      This patch fixes this by removing the DTE entry for every
      PCI device present in the system and not covered by IVRS.
      
      Cc: stable@vger.kernel.org # >= 3.0
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      af1be049
  13. 22 12月, 2011 1 次提交
  14. 15 12月, 2011 2 次提交
  15. 12 12月, 2011 11 次提交
  16. 15 11月, 2011 2 次提交
  17. 10 11月, 2011 2 次提交
  18. 21 10月, 2011 1 次提交
  19. 11 10月, 2011 1 次提交
  20. 02 9月, 2011 2 次提交