On 5/11/26 10:46 PM, David Woodhouse wrote:
> On Mon, 2026-05-11 at 14:27 -0700, Dongli Zhang wrote:
>>
>> Thank you very much for reminder! Base on my understanding of source code,
>> the
>> delta between vcpu->arch.st.last_steal and current->sched_info.run_delay (new
>> thread) won't account downtime if we handle it properly in
>> kvm_arch_vcpu_run_pid_change(). I may also add that validation to the
>> selftest.
>>
>
> Do we ever *initialize* vcpu->arch.st.last_steal to
> current->sched_info.run_delay when a vCPU is created? It looks like if
> we create a vCPU in a long-running thread, it might immediately be
> attributed a bunch of steal time due to run_delay from before it was
> even started?
>
> Xen keeps track almost identically, in vcpu->arch.xen.last_steal
> (because it's delta-based, and we can't just share arch.st.last_steal).
> The Xen does *does* initialise its last_steal... but not on vCPU
> creation, only when the runstate is restored :)
>
> On kvm_arch_vcpu_run_pid_change() you probably want to account the
> run_delay on the outgoing pid and *then* set last_steal to the
> run_delay of the new pid, yes?
>
Yes. KVM is also delta-based. Therefore, reset last_steal to run_delay so that
the delta starts from zero and is accumulated into the per-vCPU stealtime shared
memory.
> Would you mind harmonising this for native and Xen steal time
> processing as you change it, please? They should be (and should remain)
> fairly much identical.
>
Will do. Thank you very much!
Dongli Zhang
