1. 15 Oct, 2015 2 commits
  2. 09 Jan, 2014 1 commit
    • Jiang Liu's avatar
      iommu/vt-d: keep shared resources when failed to initialize iommu devices · a868e6b7
      Jiang Liu authored
      Data structure drhd->iommu is shared between DMA remapping driver and
      interrupt remapping driver, so DMA remapping driver shouldn't release
      drhd->iommu when it failed to initialize IOMMU devices. Otherwise it
      may cause invalid memory access to the interrupt remapping driver.
      
      Sample stack dump:
      [   13.315090] BUG: unable to handle kernel paging request at ffffc9000605a088
      [   13.323221] IP: [<ffffffff81461bac>] qi_submit_sync+0x15c/0x400
      [   13.330107] PGD 82f81e067 PUD c2f81e067 PMD 82e846067 PTE 0
      [   13.336818] Oops: 0002 [#1] SMP
      [   13.340757] Modules linked in:
      [   13.344422] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.13.0-rc1-gerry+ #7
      [   13.352474] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T,                                               BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [   13.365659] Workqueue: events work_for_cpu_fn
      [   13.370774] task: ffff88042ddf00d0 ti: ffff88042ddee000 task.ti: ffff88042dde                                              e000
      [   13.379389] RIP: 0010:[<ffffffff81461bac>]  [<ffffffff81461bac>] qi_submit_sy                                              nc+0x15c/0x400
      [   13.389055] RSP: 0000:ffff88042ddef940  EFLAGS: 00010002
      [   13.395151] RAX: 00000000000005e0 RBX: 0000000000000082 RCX: 0000000200000025
      [   13.403308] RDX: ffffc9000605a000 RSI: 0000000000000010 RDI: ffff88042ddb8610
      [   13.411446] RBP: ffff88042ddef9a0 R08: 00000000000005d0 R09: 0000000000000001
      [   13.419599] R10: 0000000000000000 R11: 000000000000005d R12: 000000000000005c
      [   13.427742] R13: ffff88102d84d300 R14: 0000000000000174 R15: ffff88042ddb4800
      [   13.435877] FS:  0000000000000000(0000) GS:ffff88043de00000(0000) knlGS:00000                                              00000000000
      [   13.445168] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   13.451749] CR2: ffffc9000605a088 CR3: 0000000001a0b000 CR4: 00000000000407f0
      [   13.459895] Stack:
      [   13.462297]  ffff88042ddb85d0 000000000000005d ffff88042ddef9b0 0000000000000                                              5d0
      [   13.471147]  00000000000005c0 ffff88042ddb8000 000000000000005c 0000000000000                                              015
      [   13.480001]  ffff88042ddb4800 0000000000000282 ffff88042ddefa40 ffff88042ddef                                              ac0
      [   13.488855] Call Trace:
      [   13.491771]  [<ffffffff8146848d>] modify_irte+0x9d/0xd0
      [   13.497778]  [<ffffffff8146886d>] intel_setup_ioapic_entry+0x10d/0x290
      [   13.505250]  [<ffffffff810a92a6>] ? trace_hardirqs_on_caller+0x16/0x1e0
      [   13.512824]  [<ffffffff810346b0>] ? default_init_apic_ldr+0x60/0x60
      [   13.519998]  [<ffffffff81468be0>] setup_ioapic_remapped_entry+0x20/0x30
      [   13.527566]  [<ffffffff8103683a>] io_apic_setup_irq_pin+0x12a/0x2c0
      [   13.534742]  [<ffffffff8136673b>] ? acpi_pci_irq_find_prt_entry+0x2b9/0x2d8
      [   13.544102]  [<ffffffff81037fd5>] io_apic_setup_irq_pin_once+0x85/0xa0
      [   13.551568]  [<ffffffff8103816f>] ? mp_find_ioapic_pin+0x8f/0xf0
      [   13.558434]  [<ffffffff81038044>] io_apic_set_pci_routing+0x34/0x70
      [   13.565621]  [<ffffffff8102f4cf>] mp_register_gsi+0xaf/0x1c0
      [   13.572111]  [<ffffffff8102f5ee>] acpi_register_gsi_ioapic+0xe/0x10
      [   13.579286]  [<ffffffff8102f33f>] acpi_register_gsi+0xf/0x20
      [   13.585779]  [<ffffffff81366b86>] acpi_pci_irq_enable+0x171/0x1e3
      [   13.592764]  [<ffffffff8146d771>] pcibios_enable_device+0x31/0x40
      [   13.599744]  [<ffffffff81320e9b>] do_pci_enable_device+0x3b/0x60
      [   13.606633]  [<ffffffff81322248>] pci_enable_device_flags+0xc8/0x120
      [   13.613887]  [<ffffffff813222f3>] pci_enable_device+0x13/0x20
      [   13.620484]  [<ffffffff8132fa7e>] pcie_port_device_register+0x1e/0x510
      [   13.627947]  [<ffffffff810a92a6>] ? trace_hardirqs_on_caller+0x16/0x1e0
      [   13.635510]  [<ffffffff810a947d>] ? trace_hardirqs_on+0xd/0x10
      [   13.642189]  [<ffffffff813302b8>] pcie_portdrv_probe+0x58/0xc0
      [   13.648877]  [<ffffffff81323ba5>] local_pci_probe+0x45/0xa0
      [   13.655266]  [<ffffffff8106bc44>] work_for_cpu_fn+0x14/0x20
      [   13.661656]  [<ffffffff8106fa79>] process_one_work+0x369/0x710
      [   13.668334]  [<ffffffff8106fa02>] ? process_one_work+0x2f2/0x710
      [   13.675215]  [<ffffffff81071d56>] ? worker_thread+0x46/0x690
      [   13.681714]  [<ffffffff81072194>] worker_thread+0x484/0x690
      [   13.688109]  [<ffffffff81071d10>] ? cancel_delayed_work_sync+0x20/0x20
      [   13.695576]  [<ffffffff81079c60>] kthread+0xf0/0x110
      [   13.701300]  [<ffffffff8108e7bf>] ? local_clock+0x3f/0x50
      [   13.707492]  [<ffffffff81079b70>] ? kthread_create_on_node+0x250/0x250
      [   13.714959]  [<ffffffff81574d2c>] ret_from_fork+0x7c/0xb0
      [   13.721152]  [<ffffffff81079b70>] ? kthread_create_on_node+0x250/0x250
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      a868e6b7
  3. 16 Dec, 2011 1 commit
    • Eugeni Dodonov's avatar
      iommu: Export intel_iommu_enabled to signal when iommu is in use · 8bc1f85c
      Eugeni Dodonov authored
      In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
      is enabled. The new 'intel_iommu_enabled' variable signals when the
      iommu code is in operation.
      
      Cc: Ted Phelps <phelps@gnusto.com>
      Cc: Peter <pab1612@gmail.com>
      Cc: Lukas Hejtmanek <xhejtman@fi.muni.cz>
      Cc: Andrew Lutomirski <luto@mit.edu>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      8bc1f85c
  4. 21 Sep, 2011 3 commits
  5. 01 Jun, 2011 1 commit
    • Youquan Song's avatar
      intel-iommu: Enable super page (2MiB, 1GiB, etc.) support · 6dd9a7c7
      Youquan Song authored
      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: default avatarYouquan Song <youquan.song@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      6dd9a7c7
  6. 18 May, 2009 1 commit
  7. 28 Apr, 2009 1 commit
    • Fenghua Yu's avatar
      Intel IOMMU Pass Through Support · 4ed0d3e6
      Fenghua Yu authored
      The patch adds kernel parameter intel_iommu=pt to set up pass through
      mode in context mapping entry. This disables DMAR in linux kernel; but
      KVM still runs on VT-d and interrupt remapping still works.
      
      In this mode, kernel uses swiotlb for DMA API functions but other VT-d
      functionalities are enabled for KVM. KVM always uses multi level
      translation page table in VT-d. By default, pass though mode is disabled
      in kernel.
      
      This is useful when people don't want to enable VT-d DMAR in kernel but
      still want to use KVM and interrupt remapping for reasons like DMAR
      performance concern or debug purpose.
      Signed-off-by: default avatarFenghua Yu <fenghua.yu@intel.com>
      Acked-by: default avatarWeidong Han <weidong@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      4ed0d3e6
  8. 24 Mar, 2009 1 commit
  9. 04 Jan, 2009 1 commit
    • Ingo Molnar's avatar
      intel-iommu: fix build error with INTR_REMAP=y and DMAR=n · c66b9906
      Ingo Molnar authored
      dmar.o can be built in the CONFIG_INTR_REMAP=y case but
      iommu_calculate_agaw() is only available if VT-d is built as well.
      
      So create an inline version of iommu_calculate_agaw() for the
      !CONFIG_DMAR case. The iommu->agaw value wont be used in this
      case, but the code is cleaner (has less #ifdefs) if we have it around
      unconditionally.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c66b9906
  10. 03 Jan, 2009 9 commits
  11. 18 Oct, 2008 1 commit
  12. 15 Oct, 2008 1 commit
  13. 12 Jul, 2008 2 commits