Hi Dongli, On Fri, 4 Sept 2026 at 18:56, Dongli Zhang <[email protected]> wrote: > > v1: > https://lore.kernel.org/all/[email protected] > > v1->v2: > - move the last_steal field in the main vcpu structure (suggested by > Marc Zyngier). > - Reset last_steal from the caller of kvm_arch_vcpu_run_pid_change().
I built and ran the series on QEMU/arm64: the new steal_time_change_pid selftest and the existing steal_time selftest both pass, and non-protected and protected guest boots are clean. Tested-by: Fuad Tabba <[email protected]> Cheers, /fuad > > 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. > > For instance, current->sched_info.run_delay can become smaller than > vcpu->arch.st.last_steal (see line 3804) if a QEMU vCPU is re-added after > it has previously been removed. > > As a result, st->steal restarts from a very small value, close to > current->sched_info.run_delay. > > 3720 static void record_steal_time(struct kvm_vcpu *vcpu) > 3721 { > ... ... > 3803 unsafe_get_user(steal, &st->steal, out); > 3804 steal += current->sched_info.run_delay - > 3805 vcpu->arch.st.last_steal; > 3806 vcpu->arch.st.last_steal = current->sched_info.run_delay; > 3807 unsafe_put_user(steal, &st->steal, out); > > > This patchset resets last_steal when the vCPU PID changes, as suggested by > Sean. > > Although David suggested accounting the run_delay left over from the > previous vCPU PID, this series does not do that. It would be easy to make > that work if KVM could simply assume every transition is a vCPU PID change. > In practice, KVM does not always have enough information about the previous > vCPU PID, e.g. after live migration, unless a new ioctl is introduced. For > now, this series simply resets last_steal. > > Although David also suggested doing the same for Xen-on-KVM vCPUs, this > series does not reset last_steal for Xen vCPUs. That change itself would > not be difficult, but Xen uses a different mechanism to account downtime, > including runnable time and offline time when a vCPU is not running. It may > therefore need no additional ioctl, or a smaller ioctl extension, to account > run_delay left over from the previous PID. > > As I have access to only x86 and arm64 KVM hosts, I created and validated > the selftest on those two architectures only. > > Dongli Zhang (4) > KVM: Move last_steal to common struct kvm_vcpu > KVM: Reset last_steal on vCPU pid change > KVM: selftests: Test steal time across vCPU pid changes on x86 > KVM: selftests: Add arm64 coverage for steal time pid changes > > arch/arm64/include/asm/kvm_host.h | 1 - > arch/arm64/kvm/Kconfig | 1 + > arch/arm64/kvm/pvtime.c | 8 +- > arch/loongarch/include/asm/kvm_host.h | 1 - > arch/loongarch/kvm/Kconfig | 1 + > arch/loongarch/kvm/exit.c | 2 +- > arch/loongarch/kvm/vcpu.c | 6 +- > arch/riscv/include/asm/kvm_host.h | 1 - > arch/riscv/kvm/Kconfig | 1 + > arch/riscv/kvm/vcpu_sbi_sta.c | 10 +- > arch/x86/include/asm/kvm_host.h | 1 - > arch/x86/kvm/Kconfig | 1 + > arch/x86/kvm/x86.c | 5 +- > include/linux/kvm_host.h | 4 + > tools/testing/selftests/kvm/Makefile.kvm | 2 + > .../selftests/kvm/steal_time_change_pid.c | 216 +++++++++++++++++++ > virt/kvm/Kconfig | 3 + > virt/kvm/kvm_main.c | 4 + > 18 files changed, 248 insertions(+), 20 deletions(-) > > base-commit: 8ab1afb2eb246ab15b301cd255b5943d208a93c1 > > Thank you very much! > > Dongli Zhang >
