1. 16 Apr, 2013 5 commits
  2. 14 Apr, 2013 1 commit
  3. 08 Apr, 2013 1 commit
  4. 02 Apr, 2013 1 commit
    • Paolo Bonzini's avatar
      pmu: prepare for migration support · afd80d85
      Paolo Bonzini authored
      
      
      In order to migrate the PMU state correctly, we need to restore the
      values of MSR_CORE_PERF_GLOBAL_STATUS (a read-only register) and
      MSR_CORE_PERF_GLOBAL_OVF_CTRL (which has side effects when written).
      We also need to write the full 40-bit value of the performance counter,
      which would only be possible with a v3 architectural PMU's full-width
      counter MSRs.
      
      To distinguish host-initiated writes from the guest's, pass the
      full struct msr_data to kvm_pmu_set_msr.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      afd80d85
  5. 19 Mar, 2013 2 commits
  6. 18 Mar, 2013 1 commit
  7. 14 Mar, 2013 1 commit
    • Takuya Yoshikawa's avatar
      KVM: x86: Optimize mmio spte zapping when creating/moving memslot · 982b3394
      Takuya Yoshikawa authored
      
      
      When we create or move a memory slot, we need to zap mmio sptes.
      Currently, zap_all() is used for this and this is causing two problems:
       - extra page faults after zapping mmu pages
       - long mmu_lock hold time during zapping mmu pages
      
      For the latter, Marcelo reported a disastrous mmu_lock hold time during
      hot-plug, which made the guest unresponsive for a long time.
      
      This patch takes a simple way to fix these problems: do not zap mmu
      pages unless they are marked mmio cached.  On our test box, this took
      only 50us for the 4GB guest and we did not see ms of mmu_lock hold time
      any more.
      
      Note that we still need to do zap_all() for other cases.  So another
      work is also needed: Xiao's work may be the one.
      
      Reviewed-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      982b3394
  8. 13 Mar, 2013 1 commit
    • Jan Kiszka's avatar
      KVM: x86: Rework INIT and SIPI handling · 66450a21
      Jan Kiszka authored
      
      
      A VCPU sending INIT or SIPI to some other VCPU races for setting the
      remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
      was overwritten by kvm_emulate_halt and, thus, got lost.
      
      This introduces APIC events for those two signals, keeping them in
      kvm_apic until kvm_apic_accept_events is run over the target vcpu
      context. kvm_apic_has_events reports to kvm_arch_vcpu_runnable if there
      are pending events, thus if vcpu blocking should end.
      
      The patch comes with the side effect of effectively obsoleting
      KVM_MP_STATE_SIPI_RECEIVED. We still accept it from user space, but
      immediately translate it to KVM_MP_STATE_INIT_RECEIVED + KVM_APIC_SIPI.
      The vcpu itself will no longer enter the KVM_MP_STATE_SIPI_RECEIVED
      state. That also means we no longer exit to user space after receiving a
      SIPI event.
      
      Furthermore, we already reset the VCPU on INIT, only fixing up the code
      segment later on when SIPI arrives. Moreover, we fix INIT handling for
      the BSP: it never enter wait-for-SIPI but directly starts over on INIT.
      
      Tested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      66450a21
  9. 12 Mar, 2013 2 commits
  10. 04 Mar, 2013 3 commits
  11. 27 Feb, 2013 1 commit
  12. 19 Feb, 2013 1 commit
  13. 11 Feb, 2013 1 commit
  14. 05 Feb, 2013 1 commit
  15. 29 Jan, 2013 1 commit
  16. 24 Jan, 2013 1 commit
  17. 22 Jan, 2013 3 commits
  18. 14 Jan, 2013 3 commits
  19. 08 Jan, 2013 1 commit
  20. 14 Dec, 2012 2 commits
  21. 05 Dec, 2012 1 commit
  22. 02 Dec, 2012 1 commit
  23. 30 Nov, 2012 2 commits
    • Will Auld's avatar
      KVM: x86: Emulate IA32_TSC_ADJUST MSR · ba904635
      Will Auld authored
      
      
      CPUID.7.0.EBX[1]=1 indicates IA32_TSC_ADJUST MSR 0x3b is supported
      
      Basic design is to emulate the MSR by allowing reads and writes to a guest
      vcpu specific location to store the value of the emulated MSR while adding
      the value to the vmcs tsc_offset. In this way the IA32_TSC_ADJUST value will
      be included in all reads to the TSC MSR whether through rdmsr or rdtsc. This
      is of course as long as the "use TSC counter offsetting" VM-execution control
      is enabled as well as the IA32_TSC_ADJUST control.
      
      However, because hardware will only return the TSC + IA32_TSC_ADJUST +
      vmsc tsc_offset for a guest process when it does and rdtsc (with the correct
      settings) the value of our virtualized IA32_TSC_ADJUST must be stored in one
      of these three locations. The argument against storing it in the actual MSR
      is performance. This is likely to be seldom used while the save/restore is
      required on every transition. IA32_TSC_ADJUST was created as a way to solve
      some issues with writing TSC itself so that is not an option either.
      
      The remaining option, defined above as our solution has the problem of
      returning incorrect vmcs tsc_offset values (unless we intercept and fix, not
      done here) as mentioned above. However, more problematic is that storing the
      data in vmcs tsc_offset will have a different semantic effect on the system
      than does using the actual MSR. This is illustrated in the following example:
      
      The hypervisor set the IA32_TSC_ADJUST, then the guest sets it and a guest
      process performs a rdtsc. In this case the guest process will get
      TSC + IA32_TSC_ADJUST_hyperviser + vmsc tsc_offset including
      IA32_TSC_ADJUST_guest. While the total system semantics changed the semantics
      as seen by the guest do not and hence this will not cause a problem.
      
      Signed-off-by: default avatarWill Auld <will.auld@intel.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      ba904635
    • Will Auld's avatar
      KVM: x86: Add code to track call origin for msr assignment · 8fe8ab46
      Will Auld authored
      
      
      In order to track who initiated the call (host or guest) to modify an msr
      value I have changed function call parameters along the call path. The
      specific change is to add a struct pointer parameter that points to (index,
      data, caller) information rather than having this information passed as
      individual parameters.
      
      The initial use for this capability is for updating the IA32_TSC_ADJUST msr
      while setting the tsc value. It is anticipated that this capability is
      useful for other tasks.
      
      Signed-off-by: default avatarWill Auld <will.auld@intel.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      8fe8ab46
  24. 28 Nov, 2012 3 commits