Skip to content
Snippets Groups Projects
  1. Nov 07, 2013
  2. Nov 06, 2013
  3. Nov 05, 2013
  4. Nov 04, 2013
  5. Nov 03, 2013
    • Paolo Bonzini's avatar
      KVM: x86: fix emulation of "movzbl %bpl, %eax" · daf72722
      Paolo Bonzini authored
      
      When I was looking at RHEL5.9's failure to start with
      unrestricted_guest=0/emulate_invalid_guest_state=1, I got it working with a
      slightly older tree than kvm.git.  I now debugged the remaining failure,
      which was introduced by commit 660696d1 (KVM: X86 emulator: fix
      source operand decoding for 8bit mov[zs]x instructions, 2013-04-24)
      introduced a similar mis-emulation to the one in commit 8acb4207 (KVM:
      fix sil/dil/bpl/spl in the mod/rm fields, 2013-05-30).  The incorrect
      decoding occurs in 8-bit movzx/movsx instructions whose 8-bit operand
      is sil/dil/bpl/spl.
      
      Needless to say, "movzbl %bpl, %eax" does occur in RHEL5.9's decompression
      prolog, just a handful of instructions before finally giving control to
      the decompressed vmlinux and getting out of the invalid guest state.
      
      Because OpMem8 bypasses decode_modrm, the same handling of the REX prefix
      must be applied to OpMem8.
      
      Reported-by: default avatarMichele Baldessari <michele@redhat.com>
      Cc: stable@vger.kernel.org
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      daf72722
  6. Oct 31, 2013
  7. Oct 30, 2013
  8. Oct 28, 2013
  9. Oct 18, 2013
    • Christoffer Dall's avatar
      KVM: ARM: Transparent huge page (THP) support · 9b5fdb97
      Christoffer Dall authored
      
      Support transparent huge pages in KVM/ARM and KVM/ARM64.  The
      transparent_hugepage_adjust is not very pretty, but this is also how
      it's solved on x86 and seems to be simply an artifact on how THPs
      behave.  This should eventually be shared across architectures if
      possible, but that can always be changed down the road.
      
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      9b5fdb97
    • Christoffer Dall's avatar
      KVM: ARM: Support hugetlbfs backed huge pages · ad361f09
      Christoffer Dall authored
      
      Support huge pages in KVM/ARM and KVM/ARM64.  The pud_huge checking on
      the unmap path may feel a bit silly as the pud_huge check is always
      defined to false, but the compiler should be smart about this.
      
      Note: This deals only with VMAs marked as huge which are allocated by
      users through hugetlbfs only.  Transparent huge pages can only be
      detected by looking at the underlying pages (or the page tables
      themselves) and this patch so far simply maps these on a page-by-page
      level in the Stage-2 page tables.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      ad361f09
    • 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
  10. Oct 17, 2013
Loading