1. 16 Apr, 2013 7 commits
  2. 07 Apr, 2013 1 commit
  3. 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
  4. 29 Jan, 2013 3 commits
  5. 28 Nov, 2012 1 commit
  6. 22 Oct, 2012 1 commit
  7. 20 Sep, 2012 1 commit
  8. 12 Sep, 2012 1 commit
  9. 05 Sep, 2012 1 commit
  10. 09 Aug, 2012 1 commit
  11. 06 Aug, 2012 6 commits
  12. 01 Aug, 2012 2 commits
  13. 30 Jul, 2012 1 commit
  14. 20 Jul, 2012 1 commit
  15. 25 Jun, 2012 2 commits
    • Michael S. Tsirkin's avatar
      KVM: host side for eoi optimization · ae7a2a3f
      Michael S. Tsirkin authored
      
      
      Implementation of PV EOI using shared memory.
      This reduces the number of exits an interrupt
      causes as much as by half.
      
      The idea is simple: there's a bit, per APIC, in guest memory,
      that tells the guest that it does not need EOI.
      We set it before injecting an interrupt and clear
      before injecting a nested one. Guest tests it using
      a test and clear operation - this is necessary
      so that host can detect interrupt nesting -
      and if set, it can skip the EOI MSR.
      
      There's a new MSR to set the address of said register
      in guest memory. Otherwise not much changed:
      - Guest EOI is not required
      - Register is tested & ISR is automatically cleared on exit
      
      For testing results see description of previous patch
      'kvm_para: guest side for eoi avoidance'.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      ae7a2a3f
    • Michael S. Tsirkin's avatar
      KVM: optimize ISR lookups · 8680b94b
      Michael S. Tsirkin authored
      
      
      We perform ISR lookups twice: during interrupt
      injection and on EOI. Typical workloads only have
      a single bit set there. So we can avoid ISR scans by
      1. counting bits as we set/clear them in ISR
      2. on set, caching the injected vector number
      3. on clear, invalidating the cache
      
      The real purpose of this is enabling PV EOI
      which needs to quickly validate the vector.
      But non PV guests also benefit: with this patch,
      and without interrupt nesting, apic_find_highest_isr
      will always return immediately without scanning ISR.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      8680b94b
  16. 24 Apr, 2012 1 commit
  17. 16 Apr, 2012 1 commit
    • Michael S. Tsirkin's avatar
      KVM: dont clear TMR on EOI · a0c9a822
      Michael S. Tsirkin authored
      
      
      Intel spec says that TMR needs to be set/cleared
      when IRR is set, but kvm also clears it on  EOI.
      
      I did some tests on a real (AMD based) system,
      and I see same TMR values both before
      and after EOI, so I think it's a minor bug in kvm.
      
      This patch fixes TMR to be set/cleared on IRR set
      only as per spec.
      
      And now that we don't clear TMR, we can save
      an atomic read of TMR on EOI that's not propagated
      to ioapic, by checking whether ioapic needs
      a specific vector first and calculating
      the mode afterwards.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      a0c9a822
  18. 20 Mar, 2012 1 commit
  19. 08 Mar, 2012 1 commit
    • Zachary Amsden's avatar
      KVM: Infrastructure for software and hardware based TSC rate scaling · cc578287
      Zachary Amsden authored
      
      
      This requires some restructuring; rather than use 'virtual_tsc_khz'
      to indicate whether hardware rate scaling is in effect, we consider
      each VCPU to always have a virtual TSC rate.  Instead, there is new
      logic above the vendor-specific hardware scaling that decides whether
      it is even necessary to use and updates all rate variables used by
      common code.  This means we can simply query the virtual rate at
      any point, which is needed for software rate scaling.
      
      There is also now a threshold added to the TSC rate scaling; minor
      differences and variations of measured TSC rate can accidentally
      provoke rate scaling to be used when it is not needed.  Instead,
      we have a tolerance variable called tsc_tolerance_ppm, which is
      the maximum variation from user requested rate at which scaling
      will be used.  The default is 250ppm, which is the half the
      threshold for NTP adjustment, allowing for some hardware variation.
      
      In the event that hardware rate scaling is not available, we can
      kludge a bit by forcing TSC catchup to turn on when a faster than
      hardware speed has been requested, but there is nothing available
      yet for the reverse case; this requires a trap and emulate software
      implementation for RDTSC, which is still forthcoming.
      
      [avi: fix 64-bit division on i386]
      
      Signed-off-by: default avatarZachary Amsden <zamsden@gmail.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      cc578287
  20. 05 Mar, 2012 1 commit
  21. 27 Dec, 2011 2 commits
  22. 05 Oct, 2011 1 commit
  23. 25 Sep, 2011 2 commits