Re: [REGRESSION 6.19, BISECTED] KVM: x86: kvmclock rate-limit removal causes IPI storm and high guest steal time

[Sean Christopherson]

On Wed, Apr 01, 2026, Lei Chen wrote:
> Hi Jaroslav,
> 
> I apologize for the late reply.
> 
> I have reviewed the code and identified two scenarios that currently
> trigger the KVM_REQ_GLOBAL_CLOCK_UPDATE request:
> 
> Scenario 1: kvm_write_system_time
> This code path occurs when the hypervisor (such as QEMU) adjusts the
> time, or when the guest writes to the TSC.
> 
> Scenario 2: vcpu schedule in kvm_arch_vcpu_load
> If this function triggers KVM_REQ_GLOBAL_CLOCK_UPDATE, it indicates
> that the virtual machine is not using the master_clock.
> 
> Those two cases are uncommon. Could you please provide your dmesg and
> help check which code path triggers KVM_REQ_GLOBAL_CLOCK_UPDATE?

I'm also mildly curious as to why KVM_REQ_GLOBAL_CLOCK_UPDATE is being
triggered, but I don't know that it matters.  E.g. fixing the underlying flaw
(if one even exists) could fix Jaroslav's setup, but it won't fix setups where
the "uncommon" cases are unavoidable, e.g. on setups that _can't_ use a master
clock for whatever reason.

At a glance, explicitly ratelimiting kvm_gen_kvmclock_update() seems like the
simplest option to address the regression.