1. 22 4月, 2014 7 次提交
  2. 25 3月, 2014 1 次提交
  3. 21 3月, 2014 1 次提交
  4. 21 2月, 2014 1 次提交
  5. 30 1月, 2014 1 次提交
  6. 17 1月, 2014 1 次提交
    • M
      KVM: s390: enable Transactional Execution · 7feb6bb8
      Michael Mueller 提交于
      This patch enables transactional execution for KVM guests
      on s390 systems zec12 or later.
      
      We rework the allocation of the page containing the sie_block
      to also back the Interception Transaction Diagnostic Block.
      If available the TE facilities will be enabled.
      
      Setting bit 73 and 50 in vfacilities bitmask reveals the HW
      facilities Transactional Memory and Constraint Transactional
      Memory respectively to the KVM guest.
      
      Furthermore, the patch restores the Program-Interruption TDB
      from the Interception TDB in case a program interception has
      occurred and the ITDB has a valid format.
      Signed-off-by: NMichael Mueller <mimu@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      7feb6bb8
  7. 28 11月, 2013 4 次提交
  8. 25 9月, 2013 2 次提交
  9. 29 7月, 2013 2 次提交
  10. 21 6月, 2013 1 次提交
  11. 17 6月, 2013 1 次提交
  12. 21 5月, 2013 2 次提交
  13. 02 4月, 2013 1 次提交
  14. 30 1月, 2013 1 次提交
    • C
      s390/kvm: Fix instruction decoding · 0c29b229
      Christian Borntraeger 提交于
      Instructions with long displacement have a signed displacement.
      Currently the sign bit is interpreted as 2^20: Lets fix it by doing the
      sign extension from 20bit to 32bit and then use it as a signed variable
      in the addition (see kvm_s390_get_base_disp_rsy).
      
      Furthermore, there are lots of "int" in that code. This is problematic,
      because shifting on a signed integer is undefined/implementation defined
      if the bit value happens to be negative.
      Fortunately the promotion rules will make the right hand side unsigned
      anyway, so there is no real problem right now.
      Let's convert them anyway to unsigned where appropriate to avoid
      problems if the code is changed or copy/pasted later on.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      0c29b229
  15. 08 1月, 2013 4 次提交
  16. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  17. 01 5月, 2012 1 次提交
  18. 05 3月, 2012 3 次提交
  19. 24 7月, 2011 3 次提交
  20. 01 8月, 2010 1 次提交
  21. 17 5月, 2010 1 次提交
    • 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