On Fri, 4 Sept 2026 at 18:56, Dongli Zhang <[email protected]> wrote: > > 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 <[email protected]> > Signed-off-by: Dongli Zhang <[email protected]>
Reviewed-by: Fuad Tabba <[email protected]> Cheers, /fuad > --- > 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 >
