1. 24 Jun, 2013 2 commits
  2. 21 Jun, 2013 3 commits
  3. 17 Jun, 2013 1 commit
  4. 06 Jun, 2013 1 commit
  5. 03 Jun, 2013 1 commit
    • Paolo Bonzini's avatar
      pmu: fixes for Sandy Bridge hosts · 0ef1f6a8
      Paolo Bonzini authored
      
      
      This patch includes two fixes for SB:
      
      * the 3rd fixed counter ("ref cpu cycles") can sometimes report
        less than the number of iterations
      
      * there is an 8th counter which causes out of bounds accesses
        to gp_event or check_counters_many's cnt array
      
      There is still a bug in KVM, because the "pmu all counters-0"
      test fails.  (It passes if you use any 6 of the 8 gp counters,
      fails if you use 7 or 8).
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      0ef1f6a8
  6. 20 May, 2013 1 commit
  7. 12 May, 2013 5 commits
  8. 09 May, 2013 4 commits
  9. 30 Apr, 2013 1 commit
  10. 28 Apr, 2013 4 commits
  11. 17 Apr, 2013 1 commit
  12. 14 Apr, 2013 2 commits
  13. 07 Mar, 2013 1 commit
  14. 06 Mar, 2013 1 commit
  15. 04 Mar, 2013 1 commit
  16. 27 Feb, 2013 1 commit
  17. 12 Feb, 2013 1 commit
  18. 15 Jan, 2013 2 commits
    • Xiao Guangrong's avatar
      access: add test for dirty bit tracking if CR0.WP = 0 · fcead254
      Xiao Guangrong authored
      
      
      If the write-fault access is from supervisor and CR0.WP is not set on the
      vcpu, kvm will fix it by adjusting pte access - it sets the W bit on pte
      and clears U bit. This is the chance that kvm can change pte access from
      readonly to writable
      
      Unfortunately, the pte access is the access of 'direct' shadow page table,
      means direct sp.role.access = pte_access, then we will create a writable
      spte entry on the readonly shadow page table. It will cause Dirty bit is
      not tracked when two guest ptes point to the same large page. Note, it
      does not have other impact except Dirty bit since cr0.wp is encoded into
      sp.role
      
      This testcast is not to to trigger this bug
      
      Signed-off-by: default avatarXiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      fcead254
    • Paolo Bonzini's avatar
      vmexit: time the number of cycles for simple PIO · 00bfecaa
      Paolo Bonzini authored
      
      
      This patch adds three scenarios to the vmexit test.  Two are very simple
      PIO cases that are handled in the kernel (reading from and writing
      to ELCR).  The other is an unmapped PIO that is handled in userspace.
      
      The difference between the two reading scenarios is roughly the cost of a
      userspace exit; the existing inl_from_pmtimer test is not precise enough,
      because the device model has a pretty high cost.
      
      The difference between the kernel read and write is the cost of emulation,
      because inl_from_kernel goes through the whole emulation stuff while outl
      does not (it is used for virtio, while the speed of inl matters less).
      
      Example:
      
          vmcall 3898
          inl_from_pmtimer 24615
          inl_from_qemu 20574
          inl_from_kernel 7237
          outl_to_kernel 4451
      
      So the cost of exiting to userspace is 13000 cycles on this machine,
      and the cost of emulation is 3300 cycles.
      
      Suggested-by: default avatarAvi Kivity <avi.kivity@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      00bfecaa
  19. 09 Jan, 2013 1 commit
  20. 02 Jan, 2013 1 commit
  21. 14 Dec, 2012 1 commit
  22. 13 Dec, 2012 1 commit
  23. 28 Nov, 2012 1 commit
  24. 01 Nov, 2012 1 commit
  25. 04 Sep, 2012 1 commit
    • Mao, Junjie's avatar
      Restore cr3 after tests on PCID · 6c8ef44f
      Mao, Junjie authored
      
      
      The INVPCID enabling test assumes cr3[11:0] is 0. But at present PCID enabling
      test sets cr3[11:0] to 1 for its own purpose and doesn't restore the register,
      which leads to a failure when INVPCID test tries to enable PCIDE.
      
      This patch restores cr3 after PCID enabling test is done so that PCIDE can be
      enabled normally in later tests.
      
      Signed-off-by: default avatarJunjie Mao <junjie.mao@intel.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      6c8ef44f