KVM does not support vCPU hotplug. When a vCPU is removed, its corresponding data structures are not freed by KVM. Instead, QEMU destroys only the userspace state and the vCPU thread, while the KVM vCPU fd remains open and parked in QEMU. As a result, vcpu->last_steal is not reset. If the same vCPU is later re-created by QEMU, last_steal retains its old value, while current->sched_info.run_delay starts from zero since a new vCPU thread is created. This causes current->sched_info.run_delay - vcpu->last_steal to produce a large, bogus value. Fix this by resetting vcpu->last_steal to current->sched_info.run_delay when KVM vCPU PID is changed. Suggested-by: Sean Christopherson Signed-off-by: Dongli Zhang --- v1->v2: - Move from kvm_arch_vcpu_run_pid_change() to its caller. virt/kvm/kvm_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 65eb26a0520d..784f0d945b45 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -4478,6 +4478,10 @@ static long kvm_vcpu_ioctl(struct file *filp, if (r) break; +#ifdef CONFIG_HAVE_KVM_PV_STEAL_TIME + vcpu->last_steal = current->sched_info.run_delay; +#endif + newpid = get_task_pid(current, PIDTYPE_PID); write_lock(&vcpu->pid_lock); vcpu->pid = newpid; -- 2.43.7