From: Sean Christopherson <seanjc@google.com>
To: Lei Chen <lei.chen@smartx.com>
Cc: igor@gooddata.com, jan.cipa@gooddata.com,
jaroslav.pulchart@gooddata.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, pbonzini@redhat.com
Subject: Re: [PATCH v1] KVM: x86: Rate-limit global clock updates on vCPU load
Date: Tue, 7 Apr 2026 11:02:20 -0700 [thread overview]
Message-ID: <adVGrJaRlRooO4su@google.com> (raw)
In-Reply-To: <20260407070046.2336-1-lei.chen@smartx.com>
On Tue, Apr 07, 2026, Lei Chen wrote:
> commit 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"")
> dropped the rate limiting for KVM_REQ_GLOBAL_CLOCK_UPDATE.
>
> As a result, kvm_arch_vcpu_load() can queue global clock update requests
> every time a vCPU is scheduled when the master clock is disabled or when
> the vCPU is loaded for the first time.
>
> Restore the throttling with a per-VM ratelimit state and gate
> KVM_REQ_GLOBAL_CLOCK_UPDATE through __ratelimit(), so frequent vCPU
> scheduling does not generate a steady stream of redundant clock update
> requests.
>
> Fixes: 446fcce2a52b ("Revert "x86: kvm: rate-limit global clock updates"")
> Signed-off-by: Lei Chen <lei.chen@smartx.com>
> Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
> Closes: https://lore.kernel.org/all/CAK8fFZ5gY8_Mw2A=iZVFNVKQNrXQzVsn-HTd+Me9K6ZfmdgA+Q@mail.gmail.com/
> ---
> arch/x86/include/asm/kvm_host.h | 2 ++
> arch/x86/kvm/x86.c | 5 ++++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 5a3bfa293e8b..6d3d3f19af01 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1453,6 +1453,8 @@ struct kvm_arch {
> bool use_master_clock;
> u64 master_kernel_ns;
> u64 master_cycle_now;
> + /* how often to make KVM_REQ_GLOBAL_CLOCK_UPDATE on vcpu sched*/
Eh, I would just omit this comment. If we want to document the ratelimit,
the function comment above kvm_gen_kvmclock_update() is the best place for it.
> + struct ratelimit_state kvmclock_update_rs;
>
> #ifdef CONFIG_KVM_HYPERV
> struct kvm_hv hyperv;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 63afdb6bb078..4a37027cc0b8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5211,7 +5211,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> * kvmclock on vcpu->cpu migration
> */
> if (!vcpu->kvm->arch.use_master_clock || vcpu->cpu == -1)
> - kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
> + if (__ratelimit(&vcpu->kvm->arch.kvmclock_update_rs))
> + kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
To maintain pre-revert compatibility, where KVM did this:
kvm_make_request(KVM_REQ_CLOCK_UPDATE, v);
schedule_delayed_work(&kvm->arch.kvmclock_update_work,
KVMCLOCK_UPDATE_DELAY);
the ratelimit should be on blasting KVM_REQ_CLOCK_UPDATE to *all* vCPUs, but KVM
should still trigger KVM_REQ_CLOCK_UPDATE on the initiating vCPU so that the
immediate update goes through.
That will also apply the ratelimiting to kvm_write_system_time(), though if a
guest is changing system time that fast, it probably has other issues :-)
Completely untested, but this?
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x86.c | 13 +++++--------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c470e40a00aa..f14009f25a3b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1504,6 +1504,7 @@ struct kvm_arch {
bool use_master_clock;
u64 master_kernel_ns;
u64 master_cycle_now;
+ struct ratelimit_state kvmclock_update_rs;
#ifdef CONFIG_KVM_HYPERV
struct kvm_hv hyperv;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0a1b63c63d1a..5dc33f207a83 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3522,16 +3522,12 @@ uint64_t kvm_get_wall_clock_epoch(struct kvm *kvm)
* The worst case for a remote vcpu to update its kvmclock
* is then bounded by maximum nohz sleep latency.
*/
-static void kvm_gen_kvmclock_update(struct kvm_vcpu *v)
+static void kvm_gen_kvmclock_update(struct kvm_vcpu *vcpu)
{
- unsigned long i;
- struct kvm_vcpu *vcpu;
- struct kvm *kvm = v->kvm;
-
- kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (__ratelimit(&vcpu->kvm->arch.kvmclock_update_rs))
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
- kvm_vcpu_kick(vcpu);
- }
+ else
+ kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_CLOCK_UPDATE);
}
/* These helpers are safe iff @msr is known to be an MCx bank MSR. */
@@ -13366,6 +13362,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
raw_spin_lock_init(&kvm->arch.tsc_write_lock);
mutex_init(&kvm->arch.apic_map_lock);
seqcount_raw_spinlock_init(&kvm->arch.pvclock_sc, &kvm->arch.tsc_write_lock);
+ ratelimit_state_init(&kvm->arch.kvmclock_update_rs, HZ, 10);
kvm->arch.kvmclock_offset = -get_kvmclock_base_ns();
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
base-commit: b89df297a47e641581ee67793592e5c6ae0428f4
--
prev parent reply other threads:[~2026-04-07 18:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 14:32 [REGRESSION 6.19, BISECTED] KVM: x86: kvmclock rate-limit removal causes IPI storm and high guest steal time Jaroslav Pulchart
2026-03-23 2:27 ` Lei Chen
2026-04-01 6:43 ` Lei Chen
2026-04-01 21:16 ` Sean Christopherson
2026-04-07 7:00 ` [PATCH v1] KVM: x86: Rate-limit global clock updates on vCPU load Lei Chen
2026-04-07 18:02 ` Sean Christopherson [this message]
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=adVGrJaRlRooO4su@google.com \
--to=seanjc@google.com \
--cc=igor@gooddata.com \
--cc=jan.cipa@gooddata.com \
--cc=jaroslav.pulchart@gooddata.com \
--cc=kvm@vger.kernel.org \
--cc=lei.chen@smartx.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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