Skip to content

L
linux
Switch branch/tag
  1. 01 Jun, 2011 7 commits
    • Mike Travis's avatar
      intel-iommu: Remove Host Bridge devices from identity mapping · 825507d6
      Mike Travis authored 
      When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices
that do not use the IOMMU causes a kernel panic.  Fix that by not
inserting those devices into the si_domain.
Signed-off-by: default avatarMike Travis <travis@sgi.com>
Reviewed-by: default avatarMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      825507d6
    • Mike Travis's avatar
      intel-iommu: Use coherent DMA mask when requested · c681d0ba
      Mike Travis authored 
      The __intel_map_single function is not honoring the passed in DMA mask.
This results in not using the coherent DMA mask when called from
intel_alloc_coherent().
Signed-off-by: default avatarMike Travis <travis@sgi.com>
Acked-by: default avatarChris Wright <chrisw@sous-sol.org>
Reviewed-by: default avatarMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      c681d0ba
    • Chris Wright's avatar
      intel-iommu: Dont cache iova above 32bit · 1c9fc3d1
      Chris Wright authored 
      Mike Travis and Mike Habeck reported an issue where iova allocation
would return a range that was larger than a device's dma mask.

https://lkml.org/lkml/2011/3/29/423

The dmar initialization code will reserve all PCI MMIO regions and copy
those reservations into a domain specific iova tree.  It is possible for
one of those regions to be above the dma mask of a device.  It is typical
to allocate iovas with a 32bit mask (despite device's dma mask possibly
being larger) and cache the result until it exhausts the lower 32bit
address space.  Freeing the iova range that is >= the last iova in the
lower 32bit range when there is still an iova above the 32bit range will
corrupt the cached iova by pointing it to a region that is above 32bit.
If that region is also larger than the device's dma mask, a subsequent
allocation will return an unusable iova and cause dma failure.

Simply don't cache an iova that is above the 32bit caching boundary.
Reported-by: default avatarMike Travis <travis@sgi.com>
Reported-by: default avatarMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Acked-by: default avatarMike Travis <travis@sgi.com>
Tested-by: default avatarMike Habeck <habeck@sgi.com>
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      1c9fc3d1
    • Mike Travis's avatar
      intel-iommu: Speed up processing of the identity_mapping function · cb452a40
      Mike Travis authored 
      When there are a large count of PCI devices, and the pass through
option for iommu is set, much time is spent in the identity_mapping
function hunting though the iommu domains to check if a specific
device is "identity mapped".

Speed up the function by checking the cached info to see if
it's mapped to the static identity domain.
Signed-off-by: default avatarMike Travis <travis@sgi.com>
Reviewed-by: default avatarMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      cb452a40
    • Chris Wright's avatar
      intel-iommu: Check for identity mapping candidate using system dma mask · 8fcc5372
      Chris Wright authored 
      The identity mapping code appears to make the assumption that if the
devices dma_mask is greater than 32bits the device can use identity
mapping.  But that is not true: take the case where we have a 40bit
device in a 44bit architecture. The device can potentially receive a
physical address that it will truncate and cause incorrect addresses
to be used.

Instead check to see if the device's dma_mask is large enough
to address the system's dma_mask.
Signed-off-by: default avatarMike Travis <travis@sgi.com>
Reviewed-by: default avatarMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      8fcc5372
    • Alex Williamson's avatar
      intel-iommu: Only unlink device domains from iommu · 9b4554b2
      Alex Williamson authored 
      Commit a97590e5 added unlinking domains from iommus to reciprocate the
iommu from domains unlinking that was already done.  We actually want
to only do this for device domains and never for the static
identity map domain or VM domains.  The SI domain is special and
never freed, while VM domain->id lives in their own special address
space, separate from iommu->domain_ids.

In the current code, a VM can get domain->id zero, then mark that
domain unused when unbound from pci-stub.  This leads to DMAR
write faults when the device is re-bound to the host driver.
Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      9b4554b2
    • Youquan Song's avatar
      intel-iommu: Enable super page (2MiB, 1GiB, etc.) support · 6dd9a7c7
      Youquan Song authored 
      There are no externally-visible changes with this. In the loop in the
internal __domain_mapping() function, we simply detect if we are mapping:
  - size >= 2MiB, and
  - virtual address aligned to 2MiB, and
  - physical address aligned to 2MiB, and
  - on hardware that supports superpages.

(and likewise for larger superpages).

We automatically use a superpage for such mappings. We never have to
worry about *breaking* superpages, since we trust that we will always
*unmap* the same range that was mapped. So all we need to do is ensure
that dma_pte_clear_range() will also cope with superpages.

Adjust pfn_to_dma_pte() to take a superpage 'level' as an argument, so
it can return a PTE at the appropriate level rather than always
extending the page tables all the way down to level 1. Again, this is
simplified by the fact that we should never encounter existing small
pages when we're creating a mapping; any old mapping that used the same
virtual range will have been entirely removed and its obsolete page
tables freed.

Provide an 'intel_iommu=sp_off' argument on the command line as a
chicken bit. Not that it should ever be required.

==

The original commit seen in the iommu-2.6.git was Youquan's
implementation (and completion) of my own half-baked code which I'd
typed into an email. Followed by half a dozen subsequent 'fixes'.

I've taken the unusual step of rewriting history and collapsing the
original commits in order to keep the main history simpler, and make
life easier for the people who are going to have to backport this to
older kernels. And also so I can give it a more coherent commit comment
which (hopefully) gives a better explanation of what's going on.

The original sequence of commits leading to identical code was:

Youquan Song (3):
      intel-iommu: super page support
      intel-iommu: Fix superpage alignment calculation error
      intel-iommu: Fix superpage level calculation error in dma_pfn_level_pte()

David Woodhouse (4):
      intel-iommu: Precalculate superpage support for dmar_domain
      intel-iommu: Fix hardware_largepage_caps()
      intel-iommu: Fix inappropriate use of superpages in __domain_mapping()
      intel-iommu: Fix phys_pfn in __domain_mapping for sglist pages
Signed-off-by: default avatarYouquan Song <youquan.song@intel.com>
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      6dd9a7c7
  3. 24 May, 2011 3 commits
  5. 19 May, 2011 1 commit
  7. 18 May, 2011 22 commits
  9. 17 May, 2011 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7