On 5/8/26 3:40 PM, Sean Christopherson wrote:
> 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?
Thank you very much for suggestion! I will hook kvm_arch_vcpu_run_pid_change()
and reset last_steal in there.
Dongli Zhang
