1. 28 11月, 2012 1 次提交
  2. 23 10月, 2012 1 次提交
  3. 20 9月, 2012 1 次提交
  4. 13 9月, 2012 1 次提交
  5. 05 9月, 2012 1 次提交
  6. 09 8月, 2012 1 次提交
  7. 07 8月, 2012 4 次提交
  8. 06 8月, 2012 2 次提交
  9. 01 8月, 2012 2 次提交
  10. 31 7月, 2012 1 次提交
  11. 21 7月, 2012 1 次提交
  12. 25 6月, 2012 2 次提交
    • M
      KVM: host side for eoi optimization · ae7a2a3f
      Michael S. Tsirkin 提交于
      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: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      ae7a2a3f
    • M
      KVM: optimize ISR lookups · 8680b94b
      Michael S. Tsirkin 提交于
      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: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      8680b94b
  13. 24 4月, 2012 1 次提交
  14. 17 4月, 2012 1 次提交
    • M
      KVM: dont clear TMR on EOI · a0c9a822
      Michael S. Tsirkin 提交于
      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: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      a0c9a822
  15. 20 3月, 2012 1 次提交
  16. 08 3月, 2012 1 次提交
    • Z
      KVM: Infrastructure for software and hardware based TSC rate scaling · cc578287
      Zachary Amsden 提交于
      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: NZachary Amsden <zamsden@gmail.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      cc578287
  17. 05 3月, 2012 1 次提交
  18. 27 12月, 2011 2 次提交
  19. 05 10月, 2011 1 次提交
  20. 26 9月, 2011 3 次提交
  21. 27 7月, 2011 1 次提交
  22. 18 3月, 2011 2 次提交
  23. 12 1月, 2011 1 次提交
    • A
      KVM: Avoid double interrupt injection with vapic · 83bcacb1
      Avi Kivity 提交于
      After an interrupt injection, the PPR changes, and we have to reflect that
      into the vapic.  This causes a KVM_REQ_EVENT to be set, which causes the
      whole interrupt injection routine to be run again (harmlessly).
      
      Optimize by only setting KVM_REQ_EVENT if the ppr was lowered; otherwise
      there is no chance that a new injection is needed.
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      83bcacb1
  24. 24 10月, 2010 2 次提交
  25. 23 9月, 2010 1 次提交
  26. 01 8月, 2010 4 次提交