-
Christian Borntraeger authored
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: Fan Zhang <zhangfan@linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
31d8b8d4