1. 08 3月, 2016 5 次提交
    • D
      KVM: s390: step the VCPU timer while in enabled wait · 5ebda316
      David Hildenbrand 提交于
      The cpu timer is a mean to measure task execution time. We want
      to account everything for a VCPU for which it is responsible. Therefore,
      if the VCPU wants to sleep, it shall be accounted for it.
      
      We can easily get this done by not disabling cpu timer accounting when
      scheduled out while sleeping because of enabled wait.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      5ebda316
    • D
      KVM: s390: protect VCPU cpu timer with a seqcount · 9c23a131
      David Hildenbrand 提交于
      For now, only the owning VCPU thread (that has loaded the VCPU) can get a
      consistent cpu timer value when calculating the delta. However, other
      threads might also be interested in a more recent, consistent value. Of
      special interest will be the timer callback of a VCPU that executes without
      having the VCPU loaded and could run in parallel with the VCPU thread.
      
      The cpu timer has a nice property: it is only updated by the owning VCPU
      thread. And speaking about accounting, a consistent value can only be
      calculated by looking at cputm_start and the cpu timer itself in
      one shot, otherwise the result might be wrong.
      
      As we only have one writing thread at a time (owning VCPU thread), we can
      use a seqcount instead of a seqlock and retry if the VCPU refreshed its
      cpu timer. This avoids any heavy locking and only introduces a counter
      update/check plus a handful of smp_wmb().
      
      The owning VCPU thread should never have to retry on reads, and also for
      other threads this might be a very rare scenario.
      
      Please note that we have to use the raw_* variants for locking the seqcount
      as lockdep will produce false warnings otherwise. The rq->lock held during
      vcpu_load/put is also acquired from hardirq context. Lockdep cannot know
      that we avoid potential deadlocks by disabling preemption and thereby
      disable concurrent write locking attempts (via vcpu_put/load).
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      9c23a131
    • D
      KVM: s390: step VCPU cpu timer during kvm_run ioctl · db0758b2
      David Hildenbrand 提交于
      Architecturally we should only provide steal time if we are scheduled
      away, and not if the host interprets a guest exit. We have to step
      the guest CPU timer in these cases.
      
      In the first shot, we will step the VCPU timer only during the kvm_run
      ioctl. Therefore all time spent e.g. in interception handlers or on irq
      delivery will be accounted for that VCPU.
      
      We have to take care of a few special cases:
      - Other VCPUs can test for pending irqs. We can only report a consistent
        value for the VCPU thread itself when adding the delta.
      - We have to take care of STP sync, therefore we have to extend
        kvm_clock_sync() and disable preemption accordingly
      - During any call to disable/enable/start/stop we could get premeempted
        and therefore get start/stop calls. Therefore we have to make sure we
        don't get into an inconsistent state.
      
      Whenever a VCPU is scheduled out, sleeping, in user space or just about
      to enter the SIE, the guest cpu timer isn't stepped.
      
      Please note that all primitives are prepared to be called from both
      environments (cpu timer accounting enabled or not), although not completely
      used in this patch yet (e.g. kvm_s390_set_cpu_timer() will never be called
      while cpu timer accounting is enabled).
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      db0758b2
    • D
      KVM: s390: abstract access to the VCPU cpu timer · 4287f247
      David Hildenbrand 提交于
      We want to manually step the cpu timer in certain scenarios in the future.
      Let's abstract any access to the cpu timer, so we can hide the complexity
      internally.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      4287f247
    • D
      KVM: s390: store cpu id in vcpu->cpu when scheduled in · 01a745ac
      David Hildenbrand 提交于
      By storing the cpu id, we have a way to verify if the current cpu is
      owning a VCPU.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      01a745ac
  2. 10 2月, 2016 10 次提交
  3. 26 1月, 2016 2 次提交
  4. 07 1月, 2016 2 次提交
  5. 16 12月, 2015 3 次提交
  6. 15 12月, 2015 1 次提交
  7. 30 11月, 2015 14 次提交
  8. 27 11月, 2015 1 次提交
  9. 19 11月, 2015 1 次提交
  10. 29 10月, 2015 1 次提交