Skip to content

L
linux-davinci
Switch branch/tag
  1. 16 Dec, 2009 1 commit
  3. 08 Dec, 2009 7 commits
    • KOSAKI Motohiro's avatar
      Revert "Intel IOMMU: Avoid memory allocation failures in dma map api calls" · 354bb65e
      KOSAKI Motohiro authored 
      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: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      354bb65e
    • Chris Wright's avatar
      intel-iommu: ignore page table validation in pass through mode · 1672af11
      Chris Wright authored 
      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: default avatarChris Wright <chrisw@sous-sol.org>
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      1672af11
    • David Woodhouse's avatar
      intel-iommu: Fix oops with intel_iommu=igfx_off · 44cd613c
      David Woodhouse authored 
      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: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      44cd613c
    • David Woodhouse's avatar
      intel-iommu: Check for an RMRR which ends before it starts. · 5595b528
      David Woodhouse authored 
      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: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      5595b528
    • David Woodhouse's avatar
      intel-iommu: Apply BIOS sanity checks for interrupt remapping too. · 6ecbf01c
      David Woodhouse authored 
      The BIOS errors where an IOMMU is reported either at zero or a bogus
address are causing problems even when the IOMMU is disabled -- because
interrupt remapping uses the same hardware. Ensure that the checks get
applied for the interrupt remapping initialisation too.

Cc: stable@kernel.org
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      6ecbf01c
    • Chris Wright's avatar
      intel-iommu: Detect DMAR in hyperspace at probe time. · 2c992208
      Chris Wright authored 
      Many BIOSes will lie to us about the existence of an IOMMU, and claim
that there is one at an address which actually returns all 0xFF.

We need to detect this early, so that we know we don't have a viable
IOMMU and can set up swiotlb before it's too late.

Cc: stable@kernel.org
Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      2c992208
    • David Woodhouse's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 · ec208491
      David Woodhouse authored 
      Merge the BIOS workarounds from 2.6.32, and the swiotlb fallback on failure.
      ec208491
  5. 05 Dec, 2009 9 commits
  7. 03 Dec, 2009 23 commits