[PATCH v2 0/4] KVM: Reset steal time accounting on vCPU pid change

[Dongli Zhang <dongli.zhang@oracle.com>]

v1: https://lore.kernel.org/all/20260816053630.527528-1-dongli.zhang@oracle.com

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().

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