Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 接近 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 01 6月, 2011 8 次提交
    • D
      intel-iommu: Fix off-by-one in RMRR setup · 70e535d1
      由 David Woodhouse 提交于 
      We were mapping an extra byte (and hence usually an extra page):
iommu_prepare_identity_map() expects to be given an 'end' argument which
is the last byte to be mapped; not the first byte *not* to be mapped.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      70e535d1
    • M
      intel-iommu: Add domain check in domain_remove_one_dev_info · 8519dc44
      由 Mike Habeck 提交于 
      The comment in domain_remove_one_dev_info() states "No need to compare
PCI domain; it has to be the same". But for the si_domain that isn't
going to be true, as it consists of all the PCI devices that are
identity mapped thus multiple PCI domains can be in si_domain.  The
code needs to validate the PCI domain too.
Signed-off-by: NMike Habeck <habeck@sgi.com>
Signed-off-by: NMike Travis <travis@sgi.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8519dc44
    • M
      intel-iommu: Remove Host Bridge devices from identity mapping · 825507d6
      由 Mike Travis 提交于 
      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: NMike Travis <travis@sgi.com>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      825507d6
    • M
      intel-iommu: Use coherent DMA mask when requested · c681d0ba
      由 Mike Travis 提交于 
      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: NMike Travis <travis@sgi.com>
Acked-by: NChris Wright <chrisw@sous-sol.org>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c681d0ba
    • M
      intel-iommu: Speed up processing of the identity_mapping function · cb452a40
      由 Mike Travis 提交于 
      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: NMike Travis <travis@sgi.com>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      cb452a40
    • C
      intel-iommu: Check for identity mapping candidate using system dma mask · 8fcc5372
      由 Chris Wright 提交于 
      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: NMike Travis <travis@sgi.com>
Reviewed-by: NMike Habeck <habeck@sgi.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8fcc5372
    • A
      intel-iommu: Only unlink device domains from iommu · 9b4554b2
      由 Alex Williamson 提交于 
      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: NAlex Williamson <alex.williamson@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      9b4554b2
    • Y
      intel-iommu: Enable super page (2MiB, 1GiB, etc.) support · 6dd9a7c7
      由 Youquan Song 提交于 
      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: NYouquan Song <youquan.song@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6dd9a7c7
  3. 24 5月, 2011 2 次提交
  5. 21 4月, 2011 1 次提交
    • J
      intel_iommu: disable all VT-d PMRs when TXT launched · 51a63e67
      由 Joseph Cihula 提交于 
      Intel VT-d Protected Memory Regions (PMRs) are supposed to be disabled,
on each VT-d engine, after DMA remapping is enabled on the engines.
This is because the behavior of having both enabled is not deterministic
and because, if TXT has been used to launch the kernel, the PMRs may be
programmed to cover memory regions that will be used for DMA.

Under some circumstances (certain quirks detected, lack of multiple
devices, etc.), the current code does not set up DMA remapping on some
VT-d engines.  In such cases it also skips disabling the PMRs.  This
causes failures when the kernel is launched with TXT (most often this
occurs on the graphics engine and results in colored vertical bars on
the display).

This patch detects when the kernel has been launched with TXT and then
disables the PMRs on all VT-d engines.  In some cases where the reason
that remapping is not being enabled is due to possible ACPI DMAR table
errors, the VT-d engine addresses may not be correct and thus not able
to be safely programmed even to disable PMRs.  Because part of the TXT
launch process is the verification of these addresses, it will always be
safe to disable PMRs if the TXT launch has succeeded and hence only
doing this in such cases.
Signed-off-by: NJoseph Cihula <joseph.cihula@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      51a63e67
  7. 31 3月, 2011 1 次提交
  9. 29 3月, 2011 1 次提交
  11. 24 3月, 2011 1 次提交
  13. 12 3月, 2011 2 次提交
  15. 18 1月, 2011 1 次提交
  17. 23 9月, 2010 1 次提交
  19. 22 9月, 2010 2 次提交
  21. 10 8月, 2010 1 次提交
  23. 05 8月, 2010 1 次提交
  25. 19 7月, 2010 1 次提交
  27. 15 6月, 2010 3 次提交
  29. 17 5月, 2010 2 次提交
  31. 09 4月, 2010 5 次提交
  33. 08 3月, 2010 2 次提交
  35. 17 12月, 2009 1 次提交
  37. 08 12月, 2009 4 次提交
    • K
      Revert "Intel IOMMU: Avoid memory allocation failures in dma map api calls" · 354bb65e
      由 KOSAKI Motohiro 提交于 
      commit eb3fa7cb said Intel IOMMU

    Intel IOMMU driver needs memory during DMA map calls to setup its
    internal page tables and for other data structures.  As we all know
    that these DMA map calls are mostly called in the interrupt context
    or with the spinlock held by the upper level drivers(network/storage
    drivers), so in order to avoid any memory allocation failure due to
    low memory issues, this patch makes memory allocation by temporarily
    setting PF_MEMALLOC flags for the current task before making memory
    allocation calls.

    We evaluated mempools as a backup when kmem_cache_alloc() fails
    and found that mempools are really not useful here because
     1) We don't know for sure how much to reserve in advance
     2) And mempools are not useful for GFP_ATOMIC case (as we call
        memory alloc functions with GFP_ATOMIC)

    (akpm: point 2 is wrong...)

The above description doesn't justify to waste system emergency memory
at all. Non MM subsystem must not use PF_MEMALLOC. Memory reclaim need
few memory, anyone must not prevent it. Otherwise the system cause
mysterious hang-up and/or OOM Killer invokation.

Plus, akpm already pointed out what we should do.

Then, this patch revert it.

Cc: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>
Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      354bb65e
    • C
      intel-iommu: ignore page table validation in pass through mode · 1672af11
      由 Chris Wright 提交于 
      We are seeing a bug when booting w/ iommu=pt with current upstream
(bisect blames 19943b0e "intel-iommu:
Unify hardware and software passthrough support).

The issue is specific to this loop during identity map initialization
of each device:

domain_context_mapping_one(si_domain, ..., CONTEXT_TT_PASS_THROUGH)
...
		/* Skip top levels of page tables for
		* iommu which has less agaw than default.
		*/
		for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) {
			pgd = phys_to_virt(dma_pte_addr(pgd));
			if (!dma_pte_present(pgd)) {      <------ failing here
				spin_unlock_irqrestore(&iommu->lock, flags);
			return -ENOMEM;
		}

This box has 2 iommu's in it.  The catchall iommu has MGAW == 48, and
SAGAW == 4.  The other iommu has MGAW == 39, SAGAW == 2.

The device that's failing the above pgd test is the only device connected
to the non-catchall iommu, which has a smaller address width than the
domain default.  This test is not necessary since the context is in PT
mode and the ASR is ignored.

Thanks to Don Dutile for discovering and debugging this one.

Cc: stable@kernel.org
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      1672af11
    • D
      intel-iommu: Fix oops with intel_iommu=igfx_off · 44cd613c
      由 David Woodhouse 提交于 
      The hotplug notifier will call find_domain() to see if the device in
question has been assigned an IOMMU domain. However, this should never
be called for devices with a "dummy" domain, such as graphics devices
when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even
initialised. If you do that, it'll oops as it dereferences the (-1)
pointer.

The notifier function should check iommu_no_mapping() for the
device before doing anything else.

Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      44cd613c
    • D
      intel-iommu: Check for an RMRR which ends before it starts. · 5595b528
      由 David Woodhouse 提交于 
      Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping
in the IOMMU for a given device) which has an end address lower than its
start address. Detect that and warn, rather than triggering the
BUG() in dma_pte_clear_range().

Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      5595b528