From: Dongli Zhang <dongli.zhang@oracle.com>
To: kvm@vger.kernel.org, x86@kernel.org, linux-kselftest@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com, vkuznets@redhat.com,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, shuah@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kprateek.nayak@amd.com, jgross@suse.com,
dwmw2@infradead.org, joe.jin@oracle.com
Subject: [PATCH 2/5] KVM: x86: Reset vcpu->arch.st.last_steal when enabling steal time
Date: Mon, 4 May 2026 17:30:15 -0700 [thread overview]
Message-ID: <20260505003044.78693-3-dongli.zhang@oracle.com> (raw)
In-Reply-To: <20260505003044.78693-1-dongli.zhang@oracle.com>
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.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x86.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c470e40a00aa..1f1f29128c5d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -960,6 +960,7 @@ struct kvm_vcpu_arch {
u64 msr_val;
u64 last_steal;
struct gfn_to_hva_cache cache;
+ bool need_reset;
} st;
u64 l1_tsc_offset;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0a1b63c63d1a..eec578894ad5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3829,6 +3829,12 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
smp_wmb();
unsafe_get_user(steal, &st->steal, out);
+
+ if (vcpu->arch.st.need_reset) {
+ vcpu->arch.st.need_reset = false;
+ vcpu->arch.st.last_steal = current->sched_info.run_delay;
+ }
+
steal += current->sched_info.run_delay -
vcpu->arch.st.last_steal;
vcpu->arch.st.last_steal = current->sched_info.run_delay;
@@ -4178,6 +4184,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
if (!(data & KVM_MSR_ENABLED))
break;
+ vcpu->arch.st.need_reset = true;
kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
break;
--
2.39.3
next prev parent reply other threads:[~2026-05-05 0:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 0:30 [PATCH 0/5] Fix and enhance KVM steal accounting for both guest and host Dongli Zhang
2026-05-05 0:30 ` [PATCH 1/5] x86/kvm: Reset prev_steal_time and prev_steal_time_rq when enabling steal time Dongli Zhang
2026-05-05 0:30 ` Dongli Zhang [this message]
2026-05-08 22:40 ` [PATCH 2/5] KVM: x86: Reset vcpu->arch.st.last_steal " Sean Christopherson
2026-05-10 17:09 ` David Woodhouse
2026-05-10 18:40 ` David Woodhouse
2026-05-05 0:30 ` [PATCH 3/5] KVM: x86: account KVM_SET_CLOCK downtime in " Dongli Zhang
2026-05-10 18:54 ` David Woodhouse
2026-05-10 19:11 ` H. Peter Anvin
2026-05-10 20:13 ` David Woodhouse
2026-05-05 0:30 ` [PATCH 4/5] KVM: selftests: Test steal time when re-adding a vCPU on a new thread Dongli Zhang
2026-05-05 0:30 ` [PATCH 5/5] KVM: selftests: Test KVM_SET_CLOCK downtime in steal time Dongli Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260505003044.78693-3-dongli.zhang@oracle.com \
--to=dongli.zhang@oracle.com \
--cc=bp@alien8.de \
--cc=bsegall@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joe.jin@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=tglx@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vkuznets@redhat.com \
--cc=vschneid@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox