1. 18 11月, 2014 2 次提交
  2. 06 11月, 2014 1 次提交
    • L
      x86/vt-d: Fix incorrect bit operations in setting values · 1a2262f9
      Li, Zhen-Hua 提交于
      The function context_set_address_root() and set_root_value are setting new
      address in a wrong way, and this patch is trying to fix this problem.
      
      According to Intel Vt-d specs(Feb 2011, Revision 1.3), Chapter 9.1 and 9.2,
      field ctp in root entry is using bits 12:63, field asr in context entry is
      using bits 12:63.
      
      To set these fields, the following functions are used:
      static inline void context_set_address_root(struct context_entry *context,
              unsigned long value);
      and
      static inline void set_root_value(struct root_entry *root, unsigned long value)
      
      But they are using an invalid method to set these fields, in current code, only
      a '|' operator is used to set it. This will not set the asr to the expected
      value if it has an old value.
      
      For example:
      Before calling this function,
      	context->lo = 0x3456789012111;
      	value = 0x123456789abcef12;
      
      After we call context_set_address_root(context, value), expected result is
      	context->lo == 0x123456789abce111;
      
      But the actual result is:
      	context->lo == 0x1237577f9bbde111;
      
      So we need to clear bits 12:63 before setting the new value, this will fix
      this problem.
      Signed-off-by: NLi, Zhen-Hua <zhen-hual@hp.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      1a2262f9
  3. 02 10月, 2014 3 次提交
  4. 26 9月, 2014 2 次提交
  5. 25 9月, 2014 15 次提交
  6. 24 9月, 2014 1 次提交
    • A
      kvm: Fix page ageing bugs · 57128468
      Andres Lagar-Cavilla 提交于
      1. We were calling clear_flush_young_notify in unmap_one, but we are
      within an mmu notifier invalidate range scope. The spte exists no more
      (due to range_start) and the accessed bit info has already been
      propagated (due to kvm_pfn_set_accessed). Simply call
      clear_flush_young.
      
      2. We clear_flush_young on a primary MMU PMD, but this may be mapped
      as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
      This required expanding the interface of the clear_flush_young mmu
      notifier, so a lot of code has been trivially touched.
      
      3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
      the access bit by blowing the spte. This requires proper synchronizing
      with MMU notifier consumers, like every other removal of spte's does.
      Signed-off-by: NAndres Lagar-Cavilla <andreslc@google.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      57128468
  7. 22 9月, 2014 1 次提交
  8. 17 9月, 2014 7 次提交
  9. 05 9月, 2014 3 次提交
    • V
      iommu/fsl: Fix warning resulting from adding PCI device twice · 5a9137a6
      Varun Sethi 提交于
      iommu_group_get_for_dev determines the iommu group for the PCI device and adds
      the device to the group.
      
      In the PAMU driver we were again adding the device to the same group without checking
      if the device already had an iommu group. This resulted in the following warning.
      
      sysfs: cannot create duplicate filename '/devices/ffe200000.pcie/pci0000:00/0000:00:00.0/iommu_group'
      ------------[ cut here ]------------
      WARNING: at fs/sysfs/dir.c:31
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-00002-g7505ceaf-dirty #126
      task: c0000001fe0a0000 ti: c0000001fe044000 task.ti: c0000001fe044000
      NIP: c00000000018879c LR: c000000000188798 CTR: c00000000001ea50
      REGS: c0000001fe047040 TRAP: 0700   Not tainted  (3.17.0-rc3-00002-g7505ceaf-dirty)
      MSR: 0000000080029000 <CE,EE,ME>  CR: 24ad8e22  XER: 20000000
      SOFTE: 1
      GPR00: c000000000188798 c0000001fe0472c0 c0000000009a52e0 0000000000000065
      GPR04: 0000000000000001 0000000000000000 3a30303a00000000 0000000027000000
      GPR08: 2f696f6d00000000 c0000000008d3830 c0000000009b3938 c0000000009bb3d0
      GPR12: 0000000028ad8e24 c00000000fff4000 c00000000000205c 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a4c70
      GPR24: c0000000007e9010 c0000001fe0140a8 ffffffffffffffef 0000000000000001
      GPR28: c0000001fe22ebb8 c0000000007e9010 c00000000090bf10 c0000001fe220000
      NIP [c00000000018879c] .sysfs_warn_dup+0x74/0xa4
      LR [c000000000188798] .sysfs_warn_dup+0x70/0xa4
      Call Trace:
      [c0000001fe0472c0] [c000000000188798] .sysfs_warn_dup+0x70/0xa4 (unreliable)
      [c0000001fe047350] [c000000000188d34] .sysfs_do_create_link_sd.clone.2+0x168/0x174
      [c0000001fe047400] [c0000000004b3cf8] .iommu_group_add_device+0x78/0x244
      [c0000001fe0474b0] [c0000000004b6964] .fsl_pamu_add_device+0x88/0x1a8
      [c0000001fe047570] [c0000000004b3960] .iommu_bus_notifier+0xdc/0x15c
      [c0000001fe047600] [c000000000059848] .notifier_call_chain+0x8c/0xe8
      [c0000001fe0476a0] [c000000000059d04] .__blocking_notifier_call_chain+0x58/0x84
      [c0000001fe047750] [c00000000036619c] .device_add+0x464/0x5c8
      [c0000001fe047820] [c000000000300ebc] .pci_device_add+0x14c/0x17c
      [c0000001fe0478c0] [c000000000300fbc] .pci_scan_single_device+0xd0/0xf4
      [c0000001fe047970] [c00000000030104c] .pci_scan_slot+0x6c/0x18c
      [c0000001fe047a10] [c00000000030226c] .pci_scan_child_bus+0x40/0x114
      [c0000001fe047ac0] [c000000000021974] .pcibios_scan_phb+0x240/0x2c8
      [c0000001fe047b70] [c00000000085a970] .pcibios_init+0x64/0xc8
      [c0000001fe047c00] [c000000000001884] .do_one_initcall+0xbc/0x224
      [c0000001fe047d00] [c000000000852d50] .kernel_init_freeable+0x14c/0x21c
      [c0000001fe047db0] [c000000000002078] .kernel_init+0x1c/0xfa4
      [c0000001fe047e30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
      Instruction dump:
      7c7f1b79 4182001c 7fe4fb78 7f83e378 38a01000 4bffc905 60000000 7c641b78
      e87e8008 7fa5eb78 48482ff5 60000000 <0fe00000> 7fe3fb78 4bf7bd39 60000000
      Signed-off-by: NVarun Sethi <Varun.Sethi@freescale.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5a9137a6
    • S
      iommu/omap: Fix iommu archdata name for DT-based devices · 7d682774
      Suman Anna 提交于
      A device is tied to an iommu through its archdata field. The archdata
      is allocated on the fly for DT-based devices automatically through the
      .add_device iommu ops. The current logic incorrectly assigned the name
      of the IOMMU user device, instead of the name of the IOMMU device as
      required by the attach logic. Fix this issue so that DT-based devices
      can attach successfully to an IOMMU domain.
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      7d682774
    • S
      iommu/omap: Check for valid archdata in attach_dev · e3f595b9
      Suman Anna 提交于
      Any device requiring to be attached to an iommu_domain must have
      valid archdata containing the necessary iommu information, which
      is SoC-specific. Add a check in the omap_iommu_attach_dev to make
      sure that the device has valid archdata before accessing
      different SoC-specific fields of the archdata. This prevents a
      NULL pointer dereference on any misconfigured devices.
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      e3f595b9
  10. 02 9月, 2014 4 次提交
  11. 01 9月, 2014 1 次提交
    • V
      iommu/arm-smmu: remove pgtable_page_{c,d}tor() · 93b14135
      Vladimir Murzin 提交于
      If split page table lock for PTE tables is enabled (CONFIG_SPLIT_PTLOCK_CPUS
      <=NR_CPUS) pgtable_page_ctor() leads to non-atomic allocation for ptlock with
      a spinlock held, resulting in:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 466 at kernel/locking/lockdep.c:2742 lockdep_trace_alloc+0xd8/0xf4()
      DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
      Modules linked in:
      CPU: 0 PID: 466 Comm: dma0chan0-copy0 Not tainted 3.16.0-3d47efb-clean-pl330-dma_test-ve-a15-a32-slr-m
      c-on-3+ #55
      [<80014748>] (unwind_backtrace) from [<80011640>] (show_stack+0x10/0x14)
      [<80011640>] (show_stack) from [<802bf864>] (dump_stack+0x80/0xb4)
      [<802bf864>] (dump_stack) from [<8002385c>] (warn_slowpath_common+0x64/0x88)
      [<8002385c>] (warn_slowpath_common) from [<80023914>] (warn_slowpath_fmt+0x30/0x40)
      [<80023914>] (warn_slowpath_fmt) from [<8005d818>] (lockdep_trace_alloc+0xd8/0xf4)
      [<8005d818>] (lockdep_trace_alloc) from [<800d3d78>] (kmem_cache_alloc+0x24/0x144)
      [<800d3d78>] (kmem_cache_alloc) from [<800bfae4>] (ptlock_alloc+0x18/0x2c)
      [<800bfae4>] (ptlock_alloc) from [<802b1ec0>] (arm_smmu_handle_mapping+0x4c0/0x690)
      [<802b1ec0>] (arm_smmu_handle_mapping) from [<802b0cd8>] (iommu_map+0xe0/0x148)
      [<802b0cd8>] (iommu_map) from [<80019098>] (arm_coherent_iommu_map_page+0x160/0x278)
      [<80019098>] (arm_coherent_iommu_map_page) from [<801f4d78>] (dmatest_func+0x60c/0x1098)
      [<801f4d78>] (dmatest_func) from [<8003f8ac>] (kthread+0xcc/0xe8)
      [<8003f8ac>] (kthread) from [<8000e868>] (ret_from_fork+0x14/0x2c)
      ---[ end trace ce0d27e6f434acf8 ]--
      
      Split page tables lock is not used in the driver. In fact, page tables are
      guarded with domain lock, so remove calls to pgtable_page_{c,d}tor().
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      93b14135
新手
引导
客服 返回
顶部