1. 05 3月, 2014 3 次提交
    • J
      iommu/vt-d: Avoid caching stale domain_device_info when hot-removing PCI device · 7e7dfab7
      Jiang Liu 提交于
      Function device_notifier() in intel-iommu.c only remove domain_device_info
      data structure associated with a PCI device when handling PCI device
      driver unbinding events. If a PCI device has never been bound to a PCI
      device driver, there won't be BUS_NOTIFY_UNBOUND_DRIVER event when
      hot-removing the PCI device. So associated domain_device_info data
      structure may get lost.
      
      On the other hand, if iommu_pass_through is enabled, function
      iommu_prepare_static_indentify_mapping() will create domain_device_info
      data structure for each PCIe to PCIe bridge and PCIe endpoint,
      no matter whether there are drivers associated with those PCIe devices
      or not. So those domain_device_info data structures will get lost when
      hot-removing the assocated PCIe devices if they have never bound to
      any PCI device driver.
      
      To be even worse, it's not only an memory leak issue, but also an
      caching of stale information bug because the memory are kept in
      device_domain_list and domain->devices lists.
      
      Fix the bug by trying to remove domain_device_info data structure when
      handling BUS_NOTIFY_DEL_DEVICE event.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      7e7dfab7
    • J
      iommu/vt-d: Avoid caching stale domain_device_info and fix memory leak · 816997d0
      Jiang Liu 提交于
      Function device_notifier() in intel-iommu.c fails to remove
      device_domain_info data structures for PCI devices if they are
      associated with si_domain because iommu_no_mapping() returns true
      for those PCI devices. This will cause memory leak and caching of
      stale information in domain->devices list.
      
      So fix the issue by not calling iommu_no_mapping() and skipping check
      of iommu_pass_through.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      816997d0
    • J
      iommu/vt-d: Avoid double free of g_iommus on error recovery path · 989d51fc
      Jiang Liu 提交于
      Array 'g_iommus' may be freed twice on error recovery path in function
      init_dmars() and free_dmar_iommu(), thus cause random system crash as
      below.
      
      [    6.774301] IOMMU: dmar init failed
      [    6.778310] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
      [    6.785615] software IO TLB [mem 0x76bcf000-0x7abcf000] (64MB) mapped at [ffff880076bcf000-ffff88007abcefff]
      [    6.796887] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      [    6.804173] Modules linked in:
      [    6.807731] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc1+ #108
      [    6.815122] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0047.R00.1402050741 02/05/2014
      [    6.836000] task: ffff880455a80000 ti: ffff880455a88000 task.ti: ffff880455a88000
      [    6.844487] RIP: 0010:[<ffffffff8143eea6>]  [<ffffffff8143eea6>] memcpy+0x6/0x110
      [    6.853039] RSP: 0000:ffff880455a89cc8  EFLAGS: 00010293
      [    6.859064] RAX: ffff006568636163 RBX: ffff00656863616a RCX: 0000000000000005
      [    6.867134] RDX: 0000000000000005 RSI: ffffffff81cdc439 RDI: ffff006568636163
      [    6.875205] RBP: ffff880455a89d30 R08: 000000000001bc3b R09: 0000000000000000
      [    6.883275] R10: 0000000000000000 R11: ffffffff81cdc43e R12: ffff880455a89da8
      [    6.891338] R13: ffff006568636163 R14: 0000000000000005 R15: ffffffff81cdc439
      [    6.899408] FS:  0000000000000000(0000) GS:ffff88045b800000(0000) knlGS:0000000000000000
      [    6.908575] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    6.915088] CR2: ffff88047e1ff000 CR3: 0000000001e0e000 CR4: 00000000001407f0
      [    6.923160] Stack:
      [    6.925487]  ffffffff8143c904 ffff88045b407e00 ffff006568636163 ffff006568636163
      [    6.934113]  ffffffff8120a1a9 ffffffff81cdc43e 0000000000000007 0000000000000000
      [    6.942747]  ffff880455a89da8 ffff006568636163 0000000000000007 ffffffff81cdc439
      [    6.951382] Call Trace:
      [    6.954197]  [<ffffffff8143c904>] ? vsnprintf+0x124/0x6f0
      [    6.960323]  [<ffffffff8120a1a9>] ? __kmalloc_track_caller+0x169/0x360
      [    6.967716]  [<ffffffff81440e1b>] kvasprintf+0x6b/0x80
      [    6.973552]  [<ffffffff81432bf1>] kobject_set_name_vargs+0x21/0x70
      [    6.980552]  [<ffffffff8143393d>] kobject_init_and_add+0x4d/0x90
      [    6.987364]  [<ffffffff812067c9>] ? __kmalloc+0x169/0x370
      [    6.993492]  [<ffffffff8102dbbc>] ? cache_add_dev+0x17c/0x4f0
      [    7.000005]  [<ffffffff8102ddfa>] cache_add_dev+0x3ba/0x4f0
      [    7.006327]  [<ffffffff821a87ca>] ? i8237A_init_ops+0x14/0x14
      [    7.012842]  [<ffffffff821a87f8>] cache_sysfs_init+0x2e/0x61
      [    7.019260]  [<ffffffff81002162>] do_one_initcall+0xf2/0x220
      [    7.025679]  [<ffffffff810a4a29>] ? parse_args+0x2c9/0x450
      [    7.031903]  [<ffffffff8219d1b1>] kernel_init_freeable+0x1c9/0x25b
      [    7.038904]  [<ffffffff8219c8d2>] ? do_early_param+0x8a/0x8a
      [    7.045322]  [<ffffffff8184d5e0>] ? rest_init+0x150/0x150
      [    7.051447]  [<ffffffff8184d5ee>] kernel_init+0xe/0x100
      [    7.057380]  [<ffffffff8187b87c>] ret_from_fork+0x7c/0xb0
      [    7.063503]  [<ffffffff8184d5e0>] ? rest_init+0x150/0x150
      [    7.069628] Code: 89 e5 53 48 89 fb 75 16 80 7f 3c 00 75 05 e8 d2 f9 ff ff 48 8b 43 58 48 2b 43 50 88 43 4e 5b 5d c3 90 90 90 90 48 89 f8 48 89 d1 <f3> a4 c3 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b
      [    7.094960] RIP  [<ffffffff8143eea6>] memcpy+0x6/0x110
      [    7.100856]  RSP <ffff880455a89cc8>
      [    7.104864] ---[ end trace b5d3fdc6c6c28083 ]---
      [    7.110142] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      [    7.110142]
      [    7.120540] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      989d51fc
  2. 26 2月, 2014 1 次提交
  3. 20 2月, 2014 1 次提交
  4. 11 2月, 2014 5 次提交
    • W
      iommu/arm-smmu: fix compilation issue when !CONFIG_ARM_AMBA · d123cf82
      Will Deacon 提交于
      If !CONFIG_ARM_AMBA, we shouldn't try to register ourselves with the
      amba_bustype.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      d123cf82
    • W
      iommu/arm-smmu: set CBARn.BPSHCFG to NSH for s1-s2-bypass contexts · 57ca90f6
      Will Deacon 提交于
      Whilst trying to bring-up an SMMUv2 implementation with the table
      walker plumbed into a coherent interconnect, I noticed that the memory
      transactions targetting the CPU caches from the SMMU were marked as
      outer-shareable instead of inner-shareable.
      
      After a bunch of digging, it seems that we actually need to program
      CBARn.BPSHCFG for s1-s2-bypass contexts to act as non-shareable in order
      for the shareability configured in the corresponding TTBCR not to be
      overridden with an outer-shareable attribute.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      57ca90f6
    • W
      iommu/arm-smmu: fix table flushing during initial allocations · 6dd35f45
      Will Deacon 提交于
      Now that we populate page tables as we traverse them ("iommu/arm-smmu:
      fix pud/pmd entry fill sequence"), we need to ensure that we flush out
      our zeroed tables after initial allocation, to prevent speculative TLB
      fills using bogus data.
      
      This patch adds additional calls to arm_smmu_flush_pgtable during
      initial table allocation, and moves the dsb required by coherent table
      walkers into the helper.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      6dd35f45
    • W
      iommu/arm-smmu: really fix page table locking · c9d09e27
      Will Deacon 提交于
      Commit a44a9791 ("iommu/arm-smmu: use mutex instead of spinlock for
      locking page tables") replaced the page table spinlock with a mutex, to
      allow blocking allocations to satisfy lazy mapping requests.
      
      Unfortunately, it turns out that IOMMU mappings are created from atomic
      context (e.g. spinlock held during a dma_map), so this change doesn't
      really help us in practice.
      
      This patch is a partial revert of the offending commit, bringing back
      the original spinlock but replacing our page table allocations for any
      levels below the pgd (which is allocated during domain init) with
      GFP_ATOMIC instead of GFP_KERNEL.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NAndreas Herrmann <andreas.herrmann@calxeda.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c9d09e27
    • Y
      iommu/arm-smmu: fix pud/pmd entry fill sequence · 97a64420
      Yifan Zhang 提交于
      The ARM SMMU driver's population of puds and pmds is broken, since we
      iterate over the next level of table repeatedly setting the current
      level descriptor to point at the pmd being initialised. This is clearly
      wrong when dealing with multiple pmds/puds.
      
      This patch fixes the problem by moving the pud/pmd population out of the
      loop and instead performing it when we allocate the next level (like we
      correctly do for ptes already). The starting address for the next level
      is then calculated prior to entering the loop.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NYifan Zhang <zhangyf@marvell.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      97a64420
  5. 22 1月, 2014 1 次提交
    • A
      intel-iommu: fix off-by-one in pagetable freeing · 08336fd2
      Alex Williamson 提交于
      dma_pte_free_level() has an off-by-one error when checking whether a pte
      is completely covered by a range.  Take for example the case of
      attempting to free pfn 0x0 - 0x1ff, ie.  512 entries covering the first
      2M superpage.
      
      The level_size() is 0x200 and we test:
      
        static void dma_pte_free_level(...
      	...
      
      	if (!(0 > 0 || 0x1ff < 0 + 0x200)) {
      		...
      	}
      
      Clearly the 2nd test is true, which means we fail to take the branch to
      clear and free the pagetable entry.  As a result, we're leaking
      pagetables and failing to install new pages over the range.
      
      This was found with a PCI device assigned to a QEMU guest using vfio-pci
      without a VGA device present.  The first 1M of guest address space is
      mapped with various combinations of 4K pages, but eventually the range
      is entirely freed and replaced with a 2M contiguous mapping.
      intel-iommu errors out with something like:
      
        ERROR: DMA PTE for vPFN 0x0 already set (to 5c2b8003 not 849c00083)
      
      In this case 5c2b8003 is the pointer to the previous leaf page that was
      neither freed nor cleared and 849c00083 is the superpage entry that
      we're trying to replace it with.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08336fd2
  6. 09 1月, 2014 18 次提交
    • D
      iommu/vt-d: Fix signedness bug in alloc_irte() · 9f4c7448
      Dan Carpenter 提交于
      "index" needs to be signed for the error handling to work.  I deleted a
      little bit of obsolete cruft related to "index" and "start_index" as
      well.
      
      Fixes: 360eb3c5 ('iommu/vt-d: use dedicated bitmap to track remapping entry allocation status')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      9f4c7448
    • J
      iommu/vt-d: free all resources if failed to initialize DMARs · 9bdc531e
      Jiang Liu 提交于
      Enhance intel_iommu_init() to free all resources if failed to
      initialize DMAR hardware.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      9bdc531e
    • J
      iommu/vt-d, trivial: clean sparse warnings · b707cb02
      Jiang Liu 提交于
      Clean up most sparse warnings in Intel DMA and interrupt remapping
      drivers.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      b707cb02
    • J
      iommu/vt-d: fix wrong return value of dmar_table_init() · cc05301f
      Jiang Liu 提交于
      If dmar_table_init() fails to detect DMAR table on the first call,
      it will return wrong result on following calls because it always
      sets dmar_table_initialized no matter if succeeds or fails to
      detect DMAR table.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      cc05301f
    • J
      iommu/vt-d: release invalidation queue when destroying IOMMU unit · a84da70b
      Jiang Liu 提交于
      Release associated invalidation queue when destroying IOMMU unit
      to avoid memory leak.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      a84da70b
    • J
      iommu/vt-d: fix access after free issue in function free_dmar_iommu() · 5ced12af
      Jiang Liu 提交于
      Function free_dmar_iommu() may access domain->iommu_lock by
      	spin_unlock_irqrestore(&domain->iommu_lock, flags);
      after freeing corresponding domain structure.
      
      Sample stack dump:
      [    8.912818] =========================
      [    8.917072] [ BUG: held lock freed! ]
      [    8.921335] 3.13.0-rc1-gerry+ #12 Not tainted
      [    8.926375] -------------------------
      [    8.930629] swapper/0/1 is freeing memory ffff880c23b56040-ffff880c23b5613f, with a lock still held there!
      [    8.941675]  (&(&domain->iommu_lock)->rlock){......}, at: [<ffffffff81dc775c>] init_dmars+0x72c/0x95b
      [    8.952582] 1 lock held by swapper/0/1:
      [    8.957031]  #0:  (&(&domain->iommu_lock)->rlock){......}, at: [<ffffffff81dc775c>] init_dmars+0x72c/0x95b
      [    8.968487]
      [    8.968487] stack backtrace:
      [    8.973602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ #12
      [    8.981556] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [    8.994742]  ffff880c23b56040 ffff88042dd33c98 ffffffff815617fd ffff88042dd38b28
      [    9.003566]  ffff88042dd33cd0 ffffffff810a977a ffff880c23b56040 0000000000000086
      [    9.012403]  ffff88102c4923c0 ffff88042ddb4800 ffffffff81b1e8c0 ffff88042dd33d28
      [    9.021240] Call Trace:
      [    9.024138]  [<ffffffff815617fd>] dump_stack+0x4d/0x66
      [    9.030057]  [<ffffffff810a977a>] debug_check_no_locks_freed+0x15a/0x160
      [    9.037723]  [<ffffffff811aa1c2>] kmem_cache_free+0x62/0x5b0
      [    9.044225]  [<ffffffff81465e27>] domain_exit+0x197/0x1c0
      [    9.050418]  [<ffffffff81dc7788>] init_dmars+0x758/0x95b
      [    9.056527]  [<ffffffff81dc7dfa>] intel_iommu_init+0x351/0x438
      [    9.063207]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
      [    9.069601]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
      [    9.075910]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
      [    9.082509]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
      [    9.088815]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
      [    9.095895]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
      [    9.102396]  [<ffffffff8154f580>] ? rest_init+0xd0/0xd0
      [    9.108410]  [<ffffffff8154f58e>] kernel_init+0xe/0x130
      [    9.114423]  [<ffffffff81574a2c>] ret_from_fork+0x7c/0xb0
      [    9.120612]  [<ffffffff8154f580>] ? rest_init+0xd0/0xd0
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      5ced12af
    • J
      iommu/vt-d: keep shared resources when failed to initialize iommu devices · a868e6b7
      Jiang Liu 提交于
      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: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      a868e6b7
    • J
      iommu/vt-d: fix invalid memory access when freeing DMAR irq · b5f36d9e
      Jiang Liu 提交于
      In function free_dmar_iommu(), it sets IRQ handler data to NULL
      before calling free_irq(), which will cause invalid memory access
      because free_irq() will access IRQ handler data when calling
      function dmar_msi_mask(). So only set IRQ handler data to NULL
      after calling free_irq().
      
      Sample stack dump:
      [   13.094010] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
      [   13.103215] IP: [<ffffffff810a97cd>] __lock_acquire+0x4d/0x12a0
      [   13.110104] PGD 0
      [   13.112614] Oops: 0000 [#1] SMP
      [   13.116585] Modules linked in:
      [   13.120260] CPU: 60 PID: 1 Comm: swapper/0 Tainted: G        W    3.13.0-rc1-gerry+ #9
      [   13.129367] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
      [   13.142555] task: ffff88042dd38010 ti: ffff88042dd32000 task.ti: ffff88042dd32000
      [   13.151179] RIP: 0010:[<ffffffff810a97cd>]  [<ffffffff810a97cd>] __lock_acquire+0x4d/0x12a0
      [   13.160867] RSP: 0000:ffff88042dd33b78  EFLAGS: 00010046
      [   13.166969] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0000000000000000
      [   13.175122] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000048
      [   13.183274] RBP: ffff88042dd33bd8 R08: 0000000000000002 R09: 0000000000000001
      [   13.191417] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88042dd38010
      [   13.199571] R13: 0000000000000000 R14: 0000000000000048 R15: 0000000000000000
      [   13.207725] FS:  0000000000000000(0000) GS:ffff88103f200000(0000) knlGS:0000000000000000
      [   13.217014] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   13.223596] CR2: 0000000000000048 CR3: 0000000001a0b000 CR4: 00000000000407e0
      [   13.231747] Stack:
      [   13.234160]  0000000000000004 0000000000000046 ffff88042dd33b98 ffffffff810a567d
      [   13.243059]  ffff88042dd33c08 ffffffff810bb14c ffffffff828995a0 0000000000000046
      [   13.251969]  0000000000000000 0000000000000000 0000000000000002 0000000000000000
      [   13.260862] Call Trace:
      [   13.263775]  [<ffffffff810a567d>] ? trace_hardirqs_off+0xd/0x10
      [   13.270571]  [<ffffffff810bb14c>] ? vprintk_emit+0x23c/0x570
      [   13.277058]  [<ffffffff810ab1e3>] lock_acquire+0x93/0x120
      [   13.283269]  [<ffffffff814623f7>] ? dmar_msi_mask+0x47/0x70
      [   13.289677]  [<ffffffff8156b449>] _raw_spin_lock_irqsave+0x49/0x90
      [   13.296748]  [<ffffffff814623f7>] ? dmar_msi_mask+0x47/0x70
      [   13.303153]  [<ffffffff814623f7>] dmar_msi_mask+0x47/0x70
      [   13.309354]  [<ffffffff810c0d93>] irq_shutdown+0x53/0x60
      [   13.315467]  [<ffffffff810bdd9d>] __free_irq+0x26d/0x280
      [   13.321580]  [<ffffffff810be920>] free_irq+0xf0/0x180
      [   13.327395]  [<ffffffff81466591>] free_dmar_iommu+0x271/0x2b0
      [   13.333996]  [<ffffffff810a947d>] ? trace_hardirqs_on+0xd/0x10
      [   13.340696]  [<ffffffff81461a17>] free_iommu+0x17/0x50
      [   13.346597]  [<ffffffff81dc75a5>] init_dmars+0x691/0x77a
      [   13.352711]  [<ffffffff81dc7afd>] intel_iommu_init+0x351/0x438
      [   13.359400]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
      [   13.365806]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
      [   13.372114]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
      [   13.378707]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
      [   13.385016]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
      [   13.392100]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
      [   13.398596]  [<ffffffff8154f8b0>] ? rest_init+0xd0/0xd0
      [   13.404614]  [<ffffffff8154f8be>] kernel_init+0xe/0x130
      [   13.410626]  [<ffffffff81574d6c>] ret_from_fork+0x7c/0xb0
      [   13.416829]  [<ffffffff8154f8b0>] ? rest_init+0xd0/0xd0
      [   13.422842] Code: ec 99 00 85 c0 8b 05 53 05 a5 00 41 0f 45 d8 85 c0 0f 84 ff 00 00 00 8b 05 99 f9 7e 01 49 89 fe 41 89 f7 85 c0 0f 84 03 01 00 00 <49> 8b 06 be 01 00 00 00 48 3d c0 0e 01 82 0f 44 de 41 83 ff 01
      [   13.450191] RIP  [<ffffffff810a97cd>] __lock_acquire+0x4d/0x12a0
      [   13.458598]  RSP <ffff88042dd33b78>
      [   13.462671] CR2: 0000000000000048
      [   13.466551] ---[ end trace c5bd26a37c81d760 ]---
      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>
      b5f36d9e
    • J
      iommu/vt-d, trivial: simplify code with existing macros · 7c919779
      Jiang Liu 提交于
      Simplify vt-d related code with existing macros and introduce a new
      macro for_each_active_drhd_unit() to enumerate all active DRHD unit.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      7c919779
    • J
      iommu/vt-d, trivial: use defined macro instead of hardcoding · 2fe2c602
      Jiang Liu 提交于
      Use defined macro instead of hardcoding in function set_ioapic_sid()
      for readability.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      2fe2c602
    • J
      iommu/vt-d: mark internal functions as static · 694835dc
      Jiang Liu 提交于
      Functions alloc_iommu() and parse_ioapics_under_ir()
      are only used internally, so mark them as static.
      
      [Joerg: Made detect_intel_iommu() non-static again for IA64]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      694835dc
    • J
      iommu/vt-d, trivial: clean up unused code · b8a2d288
      Jiang Liu 提交于
      Remove dead code from VT-d related files.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      
      Conflicts:
      
      	drivers/iommu/dmar.c
      b8a2d288
    • J
      iommu/vt-d, trivial: check suitable flag in function detect_intel_iommu() · b977e73a
      Jiang Liu 提交于
      Flag irq_remapping_enabled is only set by intel_enable_irq_remapping(),
      which is called after detect_intel_iommu(). So moving pr_info() from
      detect_intel_iommu() to intel_enable_irq_remapping(), which also
      slightly simplifies implementation.
      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>
      b977e73a
    • J
      iommu/vt-d, trivial: print correct domain id of static identity domain · 9544c003
      Jiang Liu 提交于
      Field si_domain->id is set by iommu_attach_domain(), so we should only
      print domain id for static identity domain after calling
      iommu_attach_domain(si_domain, iommu), otherwise it's always zero.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      9544c003
    • J
      iommu/vt-d, trivial: refine support of 64bit guest address · 5c645b35
      Jiang Liu 提交于
      In Intel IOMMU driver, it calculate page table level from adjusted guest
      address width as 'level = (agaw - 30) / 9', which assumes (agaw -30)
      could be divided by 9. On the other hand, 64bit is a valid agaw and
      (64 - 30) can't be divided by 9, so it needs special handling.
      
      This patch enhances Intel IOMMU driver to correctly handle 64bit agaw.
      It's mainly for code readability because there's no hardware supporting
      64bit agaw yet.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      5c645b35
    • J
      iommu/vt-d: fix resource leakage on error recovery path in iommu_init_domains() · 852bdb04
      Jiang Liu 提交于
      Release allocated resources on error recovery path in function
      iommu_init_domains().
      
      Also improve printk messages in iommu_init_domains().
      Acked-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      852bdb04
    • J
      iommu/vt-d: fix a race window in allocating domain ID for virtual machines · 18d99165
      Jiang Liu 提交于
      Function intel_iommu_domain_init() may be concurrently called by upper
      layer without serialization, so use atomic_t to protect domain id
      allocation.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      18d99165
    • J
      iommu/vt-d: fix PCI device reference leakage on error recovery path · ada4d4b2
      Jiang Liu 提交于
      Function dmar_parse_dev_scope() should release the PCI device reference
      count gained in function dmar_parse_one_dev_scope() on error recovery,
      otherwise it will cause PCI device object leakage.
      
      This patch also introduces dmar_free_dev_scope(), which will be used
      to support DMAR device hotplug.
      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>
      ada4d4b2
  7. 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
  8. 07 1月, 2014 7 次提交
  9. 30 12月, 2013 3 次提交