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? 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. Thanks.
smime.p7s
Description: S/MIME cryptographic signature
