On Mon, May 04, 2026, Dongli Zhang 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->arch.st.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->arch.st.last_steal to produce a > large, bogus value. > > Fix this by resetting vcpu->arch.st.last_steal to > current->sched_info.run_delay when KVM steal time is enabled.
This is quite arbitrary. E.g. if userspace hands the vCPU off to a different task without going through QEMU's hotplug dance, then current->sched_info.run_delay will also change. Shouldn't x86 hook kvm_arch_vcpu_run_pid_change() and reset last_steal in there?
