1. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  2. 25 12月, 2016 1 次提交
  3. 23 11月, 2016 2 次提交
    • C
      KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load · e1788bb9
      Christian Borntraeger 提交于
      Right now we switch the host fprs/vrs in kvm_arch_vcpu_load and switch
      back in kvm_arch_vcpu_put. This process is already optimized
      since commit 9977e886 ("s390/kernel: lazy restore fpu registers")
      avoiding double save/restores on schedule. We still reload the pointers
      and test the guest fpc on each context switch, though.
      
      We can minimize the cost of vcpu_load/put by doing the test in the
      VCPU_RUN ioctl itself. As most VCPU threads almost never exit to
      userspace in the common fast path, this allows to avoid this overhead
      for the common case (eventfd driven I/O, all exits including sleep
      handled in the kernel) - making kvm_arch_vcpu_load/put basically
      disappear in perf top.
      
      Also adapt the fpu get/set ioctls.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      e1788bb9
    • C
      KVM: s390: handle access registers in the run ioctl not in vcpu_put/load · 31d8b8d4
      Christian Borntraeger 提交于
      Right now we save the host access registers in kvm_arch_vcpu_load
      and load them in kvm_arch_vcpu_put. Vice versa for the guest access
      registers. On schedule this means, that we load/save access registers
      multiple times.
      
      e.g. VCPU_RUN with just one reschedule and then return does
      
      [from user space via VCPU_RUN]
      - save the host registers in kvm_arch_vcpu_load (via ioctl)
      - load the guest registers in kvm_arch_vcpu_load (via ioctl)
      - do guest stuff
      - decide to schedule/sleep
      - save the guest registers in kvm_arch_vcpu_put (via sched)
      - load the host registers in kvm_arch_vcpu_put (via sched)
      - save the host registers in switch_to (via sched)
      - schedule
      - return
      - load the host registers in switch_to (via sched)
      - save the host registers in kvm_arch_vcpu_load (via sched)
      - load the guest registers in kvm_arch_vcpu_load (via sched)
      - do guest stuff
      - decide to go to userspace
      - save the guest registers in kvm_arch_vcpu_put (via ioctl)
      - load the host registers in kvm_arch_vcpu_put (via ioctl)
      [back to user space]
      
      As the kernel does not use access registers, we can avoid
      this reloading and simply piggy back on switch_to (let it save
      the guest values instead of host values in thread.acrs) by
      moving the host/guest switch into the VCPU_RUN ioctl function.
      We now do
      
      [from user space via VCPU_RUN]
      - save the host registers in kvm_arch_vcpu_ioctl_run
      - load the guest registers in kvm_arch_vcpu_ioctl_run
      - do guest stuff
      - decide to schedule/sleep
      - save the guest registers in switch_to
      - schedule
      - return
      - load the guest registers in switch_to (via sched)
      - do guest stuff
      - decide to go to userspace
      - save the guest registers in kvm_arch_vcpu_ioctl_run
      - load the host registers in kvm_arch_vcpu_ioctl_run
      
      This seems to save about 10% of the vcpu_put/load functions
      according to perf.
      
      As vcpu_load no longer switches the acrs, We can also loading
      the acrs in kvm_arch_vcpu_ioctl_set_sregs.
      Suggested-by: NFan Zhang <zhangfan@linux.vnet.ibm.com>
      Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      31d8b8d4
  4. 26 10月, 2016 1 次提交
  5. 21 10月, 2016 1 次提交
    • C
      KVM: s390: reject invalid modes for runtime instrumentation · a5efb6b6
      Christian Borntraeger 提交于
      Usually a validity intercept is a programming error of the host
      because of invalid entries in the state description.
      We can get a validity intercept if the mode of the runtime
      instrumentation control block is wrong. As the host does not know
      which modes are valid, this can be used by userspace to trigger
      a WARN.
      Instead of printing a WARN let's return an error to userspace as
      this can only happen if userspace provides a malformed initial
      value (e.g. on migration). The kernel should never warn on bogus
      input. Instead let's log it into the s390 debug feature.
      
      While at it, let's return -EINVAL for all validity intercepts as
      this will trigger an error in QEMU like
      
      error: kvm run failed Invalid argument
      PSW=mask 0404c00180000000 addr 000000000063c226 cc 00
      R00=000000000000004f R01=0000000000000004 R02=0000000000760005 R03=000000007fe0a000
      R04=000000000064ba2a R05=000000049db73dd0 R06=000000000082c4b0 R07=0000000000000041
      R08=0000000000000002 R09=000003e0804042a8 R10=0000000496152c42 R11=000000007fe0afb0
      [...]
      
      This will avoid an endless loop of validity intercepts.
      
      Cc: stable@vger.kernel.org # v4.5+
      Fixes: c6e5f166 ("KVM: s390: implement the RI support of guest")
      Acked-by: NFan Zhang <zhangfan@linux.vnet.ibm.com>
      Reviewed-by: NPierre Morel <pmorel@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      a5efb6b6
  6. 16 9月, 2016 1 次提交
  7. 08 9月, 2016 10 次提交
  8. 05 9月, 2016 1 次提交
  9. 29 8月, 2016 1 次提交
  10. 26 8月, 2016 1 次提交
  11. 25 8月, 2016 1 次提交
  12. 12 8月, 2016 2 次提交
  13. 18 7月, 2016 2 次提交
  14. 14 7月, 2016 1 次提交
  15. 05 7月, 2016 1 次提交
  16. 01 7月, 2016 1 次提交
  17. 21 6月, 2016 12 次提交