1. 09 1月, 2014 10 次提交
  2. 08 1月, 2014 1 次提交
    • J
      iommu/vt-d: use dedicated bitmap to track remapping entry allocation status · 360eb3c5
      Jiang Liu 提交于
      Currently Intel interrupt remapping drivers uses the "present" flag bit
      in remapping entry to track whether an entry is allocated or not.
      It works as follow:
      1) allocate a remapping entry and set its "present" flag bit to 1
      2) compose other fields for the entry
      3) update the remapping entry with the composed value
      
      The remapping hardware may access the entry between step 1 and step 3,
      which then observers an entry with the "present" flag set but random
      values in all other fields.
      
      This patch introduces a dedicated bitmap to track remapping entry
      allocation status instead of sharing the "present" flag with hardware,
      thus eliminate the race window. It also simplifies the implementation.
      Tested-and-reviewed-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      360eb3c5
  3. 07 1月, 2014 1 次提交
  4. 30 12月, 2013 3 次提交
  5. 07 12月, 2013 3 次提交
  6. 16 11月, 2013 1 次提交
    • L
      Don't try to compile shmobile-iommu outside of ARM · f63c4824
      Linus Torvalds 提交于
      Commit 7d02c4d6 ("iommu/shmobile: Enable the driver on all ARM
      platforms") completely brokenly enabled the shmobile-iommu driver under
      COMPILE_TEST.
      
      It's bogus, because it won't compile anywhere else than ARM, since it
      tries to include <asm/dma-iommu.h>, which is very much ARM-only.
      
      So remove the bogus COMPILE_TEST dependency, which just causes
      allmodconfig to fail on non-ARM platforms.
      
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: iommu@lists.linux-foundation.org
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: Simon Horman <horms@verge.net.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f63c4824
  7. 15 11月, 2013 1 次提交
  8. 13 11月, 2013 1 次提交
  9. 01 11月, 2013 6 次提交
  10. 31 10月, 2013 1 次提交
    • L
      ACPICA: Update DMAR table definitions. · fa5f508f
      Lv Zheng 提交于
      This patch updates DMAR table header definitions as such enhancement
      has been made in ACPICA upstream already.  It ports that change to
      the Linux source to reduce source code differences between Linux and
      ACPICA upstream.
      
      Build test done on x86-64 machine with the following configs enabled:
        CONFIG_DMAR_TABLE
        CONFIG_IRQ_REMAP
        CONFIG_INTEL_IOMMU
      
      This patch does not affect the generation of the Linux kernel binary.
      
      [rjw: Changelog]
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fa5f508f
  11. 09 10月, 2013 7 次提交
  12. 05 10月, 2013 1 次提交
    • T
      x86, build, pci: Fix PCI_MSI build on !SMP · 0dbc6078
      Thomas Petazzoni 提交于
      Commit ebd97be6 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
      removed the ARCH_SUPPORTS_MSI option which architectures could select
      to indicate that they support MSI. Now, all architectures are supposed
      to build fine when MSI support is enabled: instead of having the
      architecture tell *when* MSI support can be used, it's up to the
      architecture code to ensure that MSI support can be enabled.
      
      On x86, commit ebd97be6 removed the following line:
      
        select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
      
      Which meant that MSI support was only available when the local APIC
      and I/O APIC were enabled. While this is always true on SMP or x86-64,
      it is not necessarily the case on i386 !SMP.
      
      The below patch makes sure that the local APIC and I/O APIC support is
      always enabled when MSI support is enabled. To do so, it:
      
       * Ensures the X86_UP_APIC option is not visible when PCI_MSI is
         enabled. This is the option that allows, on UP machines, to enable
         or not the APIC support. It is already not visible on SMP systems,
         or x86-64 systems, for example. We're simply also making it
         invisible on i386 MSI systems.
      
       * Ensures that the X86_LOCAL_APIC and X86_IO_APIC options are 'y'
         when PCI_MSI is enabled.
      
      Notice that this change requires a change in drivers/iommu/Kconfig to
      avoid a recursive Kconfig dependencey. The AMD_IOMMU option selects
      PCI_MSI, but was depending on X86_IO_APIC. This dependency is no
      longer needed: as soon as PCI_MSI is selected, the presence of
      X86_IO_APIC is guaranteed. Moreover, the AMD_IOMMU already depended on
      X86_64, which already guaranteed that X86_IO_APIC was enabled, so this
      dependency was anyway redundant.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Link: http://lkml.kernel.org/r/1380794354-9079-1-git-send-email-thomas.petazzoni@free-electrons.comReported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      0dbc6078
  13. 04 10月, 2013 1 次提交
    • N
      iommu: Remove stack trace from broken irq remapping warning · 05104a4e
      Neil Horman 提交于
      The warning for the irq remapping broken check in intel_irq_remapping.c is
      pretty pointless.  We need the warning, but we know where its comming from, the
      stack trace will always be the same, and it needlessly triggers things like
      Abrt.  This changes the warning to just print a text warning about BIOS being
      broken, without the stack trace, then sets the appropriate taint bit.  Since we
      automatically disable irq remapping, theres no need to contiue making Abrt jump
      at this problem
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Joerg Roedel <joro@8bytes.org>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      CC: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      05104a4e
  14. 25 9月, 2013 1 次提交
  15. 24 9月, 2013 2 次提交