1. 30 Oct, 2013 1 commit
    • Borislav Petkov's avatar
      kvm: Add KVM_GET_EMULATED_CPUID · 9c15bb1d
      Borislav Petkov authored
      Add a kvm ioctl which states which system functionality kvm emulates.
      The format used is that of CPUID and we return the corresponding CPUID
      bits set for which we do emulate functionality.
      
      Make sure ->padding is being passed on clean from userspace so that we
      can use it for something in the future, after the ioctl gets cast in
      stone.
      
      s/kvm_dev_ioctl_get_supported_cpuid/kvm_dev_ioctl_get_cpuid/ while at
      it.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9c15bb1d
  2. 28 Oct, 2013 5 commits
  3. 18 Oct, 2013 2 commits
  4. 17 Oct, 2013 3 commits
    • Christoffer Dall's avatar
      KVM: ARM: Update comments for kvm_handle_wfi · 86ed81aa
      Christoffer Dall authored
      Update comments to reflect what is really going on and add the TWE bit
      to the comments in kvm_arm.h.
      
      Also renames the function to kvm_handle_wfx like is done on arm64 for
      consistency and uber-correctness.
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      86ed81aa
    • Marc Zyngier's avatar
      ARM: KVM: Yield CPU when vcpu executes a WFE · 58d5ec8f
      Marc Zyngier authored
      On an (even slightly) oversubscribed system, spinlocks are quickly
      becoming a bottleneck, as some vcpus are spinning, waiting for a
      lock to be released, while the vcpu holding the lock may not be
      running at all.
      
      This creates contention, and the observed slowdown is 40x for
      hackbench. No, this isn't a typo.
      
      The solution is to trap blocking WFEs and tell KVM that we're
      now spinning. This ensures that other vpus will get a scheduling
      boost, allowing the lock to be released more quickly. Also, using
      CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT slightly improves the performance
      when the VM is severely overcommited.
      
      Quick test to estimate the performance: hackbench 1 process 1000
      
      2xA15 host (baseline):	1.843s
      
      2xA15 guest w/o patch:	2.083s
      4xA15 guest w/o patch:	80.212s
      8xA15 guest w/o patch:	Could not be bothered to find out
      
      2xA15 guest w/ patch:	2.102s
      4xA15 guest w/ patch:	3.205s
      8xA15 guest w/ patch:	6.887s
      
      So we go from a 40x degradation to 1.5x in the 2x overcommit case,
      which is vaguely more acceptable.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      58d5ec8f
    • Gleb Natapov's avatar
      Powerpc KVM work is based on a commit after rc4. · 13acfd57
      Gleb Natapov authored
      Merging master into next to satisfy the dependencies.
      
      Conflicts:
      	arch/arm/kvm/reset.c
      13acfd57
  5. 16 Oct, 2013 4 commits
  6. 15 Oct, 2013 8 commits
  7. 14 Oct, 2013 14 commits
  8. 13 Oct, 2013 3 commits