1. 03 1月, 2009 6 次提交
  2. 19 11月, 2008 1 次提交
    • F
      intel-iommu: fix compile warnings · b4e0f9eb
      FUJITA Tomonori 提交于
      Impact: cleanup
      
      I got the following warnings on IA64:
      
        linux-2.6/drivers/pci/intel-iommu.c: In function 'init_dmars':
        linux-2.6/drivers/pci/intel-iommu.c:1658: warning: format '%Lx' expects type 'long long unsigned int', but argument 2 has type 'u64'
        linux-2.6/drivers/pci/intel-iommu.c:1663: warning: format '%Lx' expects type 'long long unsigned int', but argument 2 has type 'u64'
      
      Another victim of int-ll64.h versus int-l64.h confusion between platforms.
      
      ->reg_base_addr has a type of u64 - which can only be printed out
      consistently if we cast its type up to LL.
      
      [ Eventually reg_base_addr should be converted to phys_addr_t, for which
        we have the %pR printk helper - but that is out of the scope of late
        -rc's. ]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b4e0f9eb
  3. 20 10月, 2008 1 次提交
  4. 18 10月, 2008 2 次提交
  5. 17 10月, 2008 1 次提交
  6. 15 10月, 2008 1 次提交
  7. 10 9月, 2008 1 次提交
  8. 06 9月, 2008 1 次提交
  9. 12 7月, 2008 6 次提交
  10. 11 7月, 2008 1 次提交
  11. 08 7月, 2008 1 次提交
  12. 11 6月, 2008 1 次提交
  13. 14 5月, 2008 1 次提交
  14. 25 4月, 2008 1 次提交
    • I
      intel-iommu.c: dma ops fix · 6865f0d1
      Ingo Molnar 提交于
      Stephen Rothwell noticed that:
      
      Commit 2be62149 ("x86: dma-ops on highmem
      fix") in Linus' tree introduced a new warning (noticed in the x86_64
      allmodconfig build of linux-next):
      
      drivers/pci/intel-iommu.c:2240: warning: initialization from incompatible pointer type
      
      Which points at an instance of map_single that needs updating.
      
      Fix it to the new prototype.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6865f0d1
  15. 21 4月, 2008 2 次提交
    • M
      PCI: pci-iommu-iotlb-flushing-speedup · 80b20dd8
      mark gross 提交于
      The following patch is an update to use an array instead of a list of
      IOVA's in the implementation of defered iotlb flushes.  It takes
      inspiration from sba_iommu.c
      
      I like this implementation better as it encapsulates the batch process
      within intel-iommu.c, and no longer touches iova.h (which is shared)
      
      Performance data:  Netperf 32byte UDP streaming
      2.6.25-rc3-mm1:
      IOMMU-strict : 58Mps @ 62% cpu
      NO-IOMMU : 71Mbs @ 41% cpu
      List-based IOMMU-default-batched-IOTLB flush: 66Mbps @ 57% cpu
      
      with this patch:
      IOMMU-strict : 73Mps @ 75% cpu
      NO-IOMMU : 74Mbs @ 42% cpu
      Array-based IOMMU-default-batched-IOTLB flush: 72Mbps @ 62% cpu
      
      Signed-off-by: <mgross@linux.intel.com>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      80b20dd8
    • M
      PCI: iommu: iotlb flushing · 5e0d2a6f
      mark gross 提交于
      This patch is for batching up the flushing of the IOTLB for the DMAR
      implementation found in the Intel VT-d hardware.  It works by building a list
      of to be flushed IOTLB entries and a bitmap list of which DMAR engine they are
      from.
      
      After either a high water mark (250 accessible via debugfs) or 10ms the list
      of iova's will be reclaimed and the DMAR engines associated are IOTLB-flushed.
      
      This approach recovers 15 to 20% of the performance lost when using the IOMMU
      for my netperf udp stream benchmark with small packets.  It can be disabled
      with a kernel boot parameter "intel_iommu=strict".
      
      Its use does weaken the IOMMU protections a bit.
      Signed-off-by: NMark Gross <mgross@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5e0d2a6f
  16. 25 3月, 2008 1 次提交
    • M
      PCI: iova: lockdep false alarm fix · 8a443df4
      Mark Gross 提交于
      lockdep goes off on the iova copy_reserved_iova() because it and a function
      it calls grabs locks in the from, and the to of the copy operation.
      
      The function grab locks of the same lock classes triggering the warning.  The
      first lock grabbed is for the constant reserved areas that is never accessed
      after early boot.  Technically you could do without grabbing the locks for the
      "from" structure its copying reserved areas from.
      
      But dropping the from locks to me looks wrong, even though it would be ok.
      
      The affected code only runs in early boot as its setting up the DMAR
      engines.
      
      This patch gives the reserved_ioval_list locks special lockdep classes.
      Signed-off-by: NMark Gross <mgross@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8a443df4
  17. 24 2月, 2008 1 次提交
  18. 09 2月, 2008 2 次提交
  19. 07 2月, 2008 1 次提交
  20. 02 2月, 2008 1 次提交
  21. 30 10月, 2007 2 次提交
  22. 29 10月, 2007 1 次提交
  23. 23 10月, 2007 1 次提交
  24. 22 10月, 2007 3 次提交