1. 13 12月, 2013 1 次提交
  2. 17 10月, 2013 1 次提交
  3. 18 7月, 2013 1 次提交
  4. 30 4月, 2013 1 次提交
  5. 28 4月, 2013 1 次提交
  6. 18 4月, 2013 1 次提交
  7. 05 3月, 2013 4 次提交
  8. 14 12月, 2012 2 次提交
  9. 28 11月, 2012 1 次提交
  10. 19 11月, 2012 1 次提交
  11. 27 10月, 2012 1 次提交
  12. 06 9月, 2012 1 次提交
  13. 26 7月, 2012 1 次提交
  14. 09 5月, 2012 1 次提交
  15. 20 4月, 2012 2 次提交
  16. 08 4月, 2012 1 次提交
  17. 08 3月, 2012 2 次提交
  18. 05 3月, 2012 2 次提交
  19. 27 12月, 2011 3 次提交
  20. 21 10月, 2011 1 次提交
    • J
      iommu/core: Convert iommu_found to iommu_present · a1b60c1c
      Joerg Roedel 提交于
      With per-bus iommu_ops the iommu_found function needs to
      work on a bus_type too. This patch adds a bus_type parameter
      to that function and converts all call-places.
      The function is also renamed to iommu_present because the
      function now checks if an iommu is present for a given bus
      and does not check for a global iommu anymore.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      a1b60c1c
  21. 18 3月, 2011 1 次提交
    • X
      KVM: Add "exiting guest mode" state · 6b7e2d09
      Xiao Guangrong 提交于
      Currently we keep track of only two states: guest mode and host
      mode.  This patch adds an "exiting guest mode" state that tells
      us that an IPI will happen soon, so unless we need to wait for the
      IPI, we can avoid it completely.
      
      Also
      1: No need atomically to read/write ->mode in vcpu's thread
      
      2: reorganize struct kvm_vcpu to make ->mode and ->requests
         in the same cache line explicitly
      Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      6b7e2d09
  22. 12 1月, 2011 2 次提交
  23. 01 8月, 2010 4 次提交
  24. 17 6月, 2010 1 次提交
  25. 09 6月, 2010 1 次提交
  26. 17 5月, 2010 2 次提交
    • L
      KVM: use the correct RCU API for PROVE_RCU=y · 90d83dc3
      Lai Jiangshan 提交于
      The RCU/SRCU API have already changed for proving RCU usage.
      
      I got the following dmesg when PROVE_RCU=y because we used incorrect API.
      This patch coverts rcu_deference() to srcu_dereference() or family API.
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      arch/x86/kvm/mmu.c:3020 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 0
      2 locks held by qemu-system-x86/8550:
       #0:  (&kvm->slots_lock){+.+.+.}, at: [<ffffffffa011a6ac>] kvm_set_memory_region+0x29/0x50 [kvm]
       #1:  (&(&kvm->mmu_lock)->rlock){+.+...}, at: [<ffffffffa012262d>] kvm_arch_commit_memory_region+0xa6/0xe2 [kvm]
      
      stack backtrace:
      Pid: 8550, comm: qemu-system-x86 Not tainted 2.6.34-rc4-tip-01028-g939eab1 #27
      Call Trace:
       [<ffffffff8106c59e>] lockdep_rcu_dereference+0xaa/0xb3
       [<ffffffffa012f6c1>] kvm_mmu_calculate_mmu_pages+0x44/0x7d [kvm]
       [<ffffffffa012263e>] kvm_arch_commit_memory_region+0xb7/0xe2 [kvm]
       [<ffffffffa011a5d7>] __kvm_set_memory_region+0x636/0x6e2 [kvm]
       [<ffffffffa011a6ba>] kvm_set_memory_region+0x37/0x50 [kvm]
       [<ffffffffa015e956>] vmx_set_tss_addr+0x46/0x5a [kvm_intel]
       [<ffffffffa0126592>] kvm_arch_vm_ioctl+0x17a/0xcf8 [kvm]
       [<ffffffff810a8692>] ? unlock_page+0x27/0x2c
       [<ffffffff810bf879>] ? __do_fault+0x3a9/0x3e1
       [<ffffffffa011b12f>] kvm_vm_ioctl+0x364/0x38d [kvm]
       [<ffffffff81060cfa>] ? up_read+0x23/0x3d
       [<ffffffff810f3587>] vfs_ioctl+0x32/0xa6
       [<ffffffff810f3b19>] do_vfs_ioctl+0x495/0x4db
       [<ffffffff810e6b2f>] ? fget_light+0xc2/0x241
       [<ffffffff810e416c>] ? do_sys_open+0x104/0x116
       [<ffffffff81382d6d>] ? retint_swapgs+0xe/0x13
       [<ffffffff810f3ba6>] sys_ioctl+0x47/0x6a
       [<ffffffff810021db>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      90d83dc3
    • W
      KVM: ia64: fix the error of ioctl KVM_IRQ_LINE if no irq chip · 600f1ec3
      Wei Yongjun 提交于
      If no irq chip in kernel, ioctl KVM_IRQ_LINE will return -EFAULT.
      But I see in other place such as KVM_[GET|SET]IRQCHIP, -ENXIO is
      return. So this patch used -ENXIO instead of -EFAULT.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      600f1ec3