1. 28 Mar, 2012 1 commit
  2. 10 Jun, 2011 1 commit
  3. 18 Mar, 2011 1 commit
  4. 26 Aug, 2010 2 commits
    • Konrad Rzeszutek Wilk's avatar
      x86, calgary: Make Calgary IOMMU use IOMMU_INIT_* macros. · d2aa232f
      Konrad Rzeszutek Wilk authored
      We utilize the IOMMU_INIT macros to create this dependency:
      
           [pci_xen_swiotlb_detect]
               |
           [pci_swiotlb_detect_override]
               |
           [pci_swiotlb_detect_4gb]
               |
            [detect_calgary]
      
      Meaning that 'detect_calgary' is going to be called after
      'pci_swiotlb_detect'.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      LKML-Reference: <1282845485-8991-8-git-send-email-konrad.wilk@oracle.com>
      CC: Muli Ben-Yehuda <muli@il.ibm.com>
      CC: "Jon D. Mason" <jdmason@kudzu.us>
      CC: "Darrick J. Wong" <djwong@us.ibm.com>
      CC: Fujita Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      d2aa232f
    • Konrad Rzeszutek Wilk's avatar
      x86, iommu: Make all IOMMU's detection routines return a value. · 480125ba
      Konrad Rzeszutek Wilk authored
      We return 1 if the IOMMU has been detected. Zero or an error number
      if we failed to find it. This is in preperation of using the IOMMU_INIT
      so that we can detect whether an IOMMU is present. I have not
      tested this for regression on Calgary, nor on AMD Vi chipsets as
      I don't have that hardware.
      
      CC: Muli Ben-Yehuda <muli@il.ibm.com>
      CC: "Jon D. Mason" <jdmason@kudzu.us>
      CC: "Darrick J. Wong" <djwong@us.ibm.com>
      CC: Jesse Barnes <jbarnes@virtuousgeek.org>
      CC: David Woodhouse <David.Woodhouse@intel.com>
      CC: Chris Wright <chrisw@sous-sol.org>
      CC: Yinghai Lu <yinghai@kernel.org>
      CC: Joerg Roedel <joerg.roedel@amd.com>
      CC: H. Peter Anvin <hpa@zytor.com>
      CC: Fujita Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      LKML-Reference: <1282845485-8991-3-git-send-email-konrad.wilk@oracle.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      480125ba
  5. 30 Jun, 2010 1 commit
  6. 25 Jun, 2010 1 commit
  7. 09 Feb, 2010 1 commit
  8. 16 Dec, 2009 1 commit
    • Akinobu Mita's avatar
      iommu-helper: use bitmap library · a66022c4
      Akinobu Mita authored
      Use bitmap library and kill some unused iommu helper functions.
      
      1. s/iommu_area_free/bitmap_clear/
      
      2. s/iommu_area_reserve/bitmap_set/
      
      3. Use bitmap_find_next_zero_area instead of find_next_zero_area
      
        This cannot be simple substitution because find_next_zero_area
        doesn't check the last bit of the limit in bitmap
      
      4. Remove iommu_area_free, iommu_area_reserve, and find_next_zero_area
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a66022c4
  9. 03 Dec, 2009 1 commit
    • Darrick J. Wong's avatar
      x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree · 4528752f
      Darrick J. Wong authored
      On a multi-node x3950M2 system, there's a slight oddity in the
      PCI device tree for all secondary nodes:
      
       30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
        \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
           \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
      
      ...as compared to the primary node:
      
       00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
        \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
       03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
        \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
      
      In both nodes, the LSI RAID controller hangs off a CalIOC2
      device, but on the secondary nodes, the BIOS hides the VGA
      device and substitutes the device tree ending with the disk
      controller.
      
      It would seem that Calgary devices don't necessarily appear at
      the top of the PCI tree, which means that the current code to
      find the Calgary IOMMU that goes with a particular device is
      buggy.
      
      Rather than walk all the way to the top of the PCI
      device tree and try to match bus number with Calgary descriptor,
      the code needs to examine each parent of the particular device;
      if it encounters a Calgary with a matching bus number, simply
      use that.
      
      Otherwise, we BUG() when the bus number of the Calgary doesn't
      match the bus number of whatever's at the top of the device tree.
      
      Extra note: This patch appears to work correctly for the x3950
      that came before the x3950 M2.
      Signed-off-by: default avatarDarrick J. Wong <djwong@us.ibm.com>
      Acked-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jon D. Mason <jdmason@kudzu.us>
      Cc: Corinna Schultz <coschult@us.ibm.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4528752f
  10. 16 Nov, 2009 2 commits
  11. 15 Nov, 2009 1 commit
  12. 10 Nov, 2009 2 commits
    • FUJITA Tomonori's avatar
      x86: Handle HW IOMMU initialization failure gracefully · 75f1cdf1
      FUJITA Tomonori authored
      If HW IOMMU initialization fails (Intel VT-d often does this,
      typically due to BIOS bugs), we fall back to nommu. It doesn't
      work for the majority since nowadays we have more than 4GB
      memory so we must use swiotlb instead of nommu.
      
      The problem is that it's too late to initialize swiotlb when HW
      IOMMU initialization fails. We need to allocate swiotlb memory
      earlier from bootmem allocator. Chris explained the issue in
      detail:
      
        http://marc.info/?l=linux-kernel&m=125657444317079&w=2
      
      The current x86 IOMMU initialization sequence is too complicated
      and handling the above issue makes it more hacky.
      
      This patch changes x86 IOMMU initialization sequence to handle
      the above issue cleanly.
      
      The new x86 IOMMU initialization sequence are:
      
      1. we initialize the swiotlb (and setting swiotlb to 1) in the case
         of (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to
         swiotlb_dma_ops or nommu_dma_ops. if swiotlb usage is forced by
         the boot option, we finish here.
      
      2. we call the detection functions of all the IOMMUs
      
      3. the detection function sets x86_init.iommu.iommu_init to the
         IOMMU initialization function (so we can avoid calling the
         initialization functions of all the IOMMUs needlessly).
      
      4. if the IOMMU initialization function doesn't need to swiotlb
         then sets swiotlb to zero (e.g. the initialization is
         sucessful).
      
      5. if we find that swiotlb is set to zero, we free swiotlb
         resource.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      Cc: muli@il.ibm.com
      LKML-Reference: <1257849980-22640-10-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      75f1cdf1
    • FUJITA Tomonori's avatar
      x86: Calgary: Convert detect_calgary() to use iommu_init hook · d7b9f7be
      FUJITA Tomonori authored
      This changes detect_calgary() to set init_calgary() to
      iommu_init hook if detect_calgary() finds the Calgary IOMMU.
      
      We can kill the code to check if we found the IOMMU in
      init_calgary() since detect_calgary() sets init_calgary() only
      when it found the IOMMU.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Cc: chrisw@sous-sol.org
      Cc: dwmw2@infradead.org
      Cc: joerg.roedel@amd.com
      LKML-Reference: <1257849980-22640-3-git-send-email-fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d7b9f7be
  13. 14 Apr, 2009 1 commit
    • FUJITA Tomonori's avatar
      x86: calgary: remove IOMMU_DEBUG · 7e05575c
      FUJITA Tomonori authored
      CONFIG_IOMMU_DEBUG has depends on CONFIG_GART_IOMMU:
      
      config IOMMU_DEBUG
      	bool "Enable IOMMU debugging"
      	depends on GART_IOMMU && DEBUG_KERNEL
      	depends on X86_64
      
      So it's not useful to have CONFIG_IOMMU_DEBUG in Calgary IOMMU code,
      which does the extra checking of the bitmap space management.
      
      And Calgary uses the iommu helper for the bitmap space management now
      so it would be better to have the extra checking feature in the iommu
      helper rather than Calgary code (if necessary).
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: alexisb@us.ibm.com
      LKML-Reference: <20090414120827G.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7e05575c
  14. 06 Jan, 2009 3 commits
  15. 25 Nov, 2008 1 commit
  16. 16 Oct, 2008 1 commit
  17. 22 Sep, 2008 1 commit
  18. 14 Sep, 2008 1 commit
  19. 22 Aug, 2008 1 commit
  20. 21 Aug, 2008 2 commits
  21. 18 Aug, 2008 1 commit
    • Marcin Slusarz's avatar
      x86, calgary: fix section mismatch warning - get_tce_space_from_tar · f7106662
      Marcin Slusarz authored
      WARNING: vmlinux.o(.text+0x27032): Section mismatch in reference from the function get_tce_space_from_tar() to the function .init.text:calgary_bus_has_devices()
      The function get_tce_space_from_tar() references
      the function __init calgary_bus_has_devices().
      This is often because get_tce_space_from_tar lacks a __init
      annotation or the annotation of calgary_bus_has_devices is wrong.
      
      get_tce_space_from_tar is called only from __init function (calgary_init)
      and calls __init function (calgary_bus_has_devices).
      So annotate it properly.
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Chandru Siddalingappa <chandru@in.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f7106662
  22. 11 Aug, 2008 1 commit
  23. 26 Jul, 2008 2 commits
    • Alexis Bruemmer's avatar
      x86 calgary: fix handling of devices that aren't behind the Calgary · 1956a96d
      Alexis Bruemmer authored
      The calgary code can give drivers addresses above 4GB which is very bad
      for hardware that is only 32bit DMA addressable.
      
      With this patch, the calgary code sets the global dma_ops to swiotlb or
      nommu properly, and the dma_ops of devices behind the Calgary/CalIOC2
      to calgary_dma_ops.  So the calgary code can handle devices safely that
      aren't behind the Calgary/CalIOC2.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarAlexis Bruemmer <alexisb@us.ibm.com>
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1956a96d
    • FUJITA Tomonori's avatar
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori authored
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  24. 25 Jul, 2008 1 commit
  25. 11 Jul, 2008 1 commit
  26. 08 Jul, 2008 1 commit
  27. 26 Apr, 2008 1 commit
  28. 20 Apr, 2008 1 commit
  29. 19 Apr, 2008 1 commit
  30. 05 Feb, 2008 1 commit
  31. 01 Feb, 2008 1 commit
  32. 30 Jan, 2008 2 commits