Re: [PATCH] KVM: x86: Guard against division by zero in adjust_lapic_timer_advance()

[Sean Christopherson <seanjc@google.com>]

On Sat, Oct 10, 2026, Hao Peng wrote:
> On Sat, Oct 10, 2026 at 4:35 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Thu, Oct 08, 2026, Peng Hao wrote:
> > > When TSC calibration fails and userspace never programs a tsc khz,
> > > vcpu->arch.virtual_tsc_khz stays zero, but the lapic timer's
> > > software-mode expiry path still calls adjust_lapic_timer_advance()
> > > unconditionally on every timer expiration (unlike
> > > __wait_lapic_expire(), this path is not gated on tsc_scaling_ratio).
> > > Both the "too early" and "too late" branches do_div() by
> > > virtual_tsc_khz, so a zero khz crashes the host with #DE as soon as
> > > the timer advance drifts outside the adjust window.
> > >
> > > Bail out before either division.
> > >
> > > Signed-off-by: Peng Hao <flyingpeng@tencent.com>
> > > ---
> > >  arch/x86/kvm/lapic.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > > index 13e32c4915e2..4dcbc66c8e07 100644
> > > --- a/arch/x86/kvm/lapic.c
> > > +++ b/arch/x86/kvm/lapic.c
> > > @@ -1991,6 +1991,9 @@ static inline void adjust_lapic_timer_advance(struct kvm_vcpu *vcpu,
> > >           abs(advance_expire_delta) < LAPIC_TIMER_ADVANCE_ADJUST_MIN)
> > >               return;
> > >
> > > +     if (unlikely(!vcpu->arch.virtual_tsc_khz))
> > > +             return;
> >
> > Ugh.  I'd rather reject KVM_CREATE_VCPU, even though there is a rather surprising
> > amount of code in KVM that does indeed play nice with tsc_khz == 0.  I don't see
> > how the guest can possibly function with virtual_tsc_khz==0.
> >
> Agreed the guest is broken in that state -- virtual_tsc_mult is zero too, so
> nsec_to_cycles() returns 0 and the deadline timer fires immediately. But I don't
> think KVM_CREATE_VCPU is where to enforce it, because letting vCPU creation
>  succeed is what makes the state recoverable:
>   - kvm_arch_vcpu_create() deliberately ignores kvm_set_tsc_khz()'s -1
>   - KVM_SET_TSC_KHZ is only reachable once the vCPU exists. With
>       kvm_caps.has_tsc_control and a khz below kvm_caps.max_guest_tsc_khz it
>       recomputes virtual_tsc_{shift,mult} and the guest is fully
> functional again.
>  - max_tsc_khz does the same thing ahead of time, via default_tsc_khz.

I don't see how it's recoverable.  kvm_set_tsc_khz() will compute thresh_{lo,hi}=0,
and so use_scaling will always be true.  Which means this:

	ratio = mul_u64_u32_div(1ULL << kvm_caps.tsc_scaling_ratio_frac_bits,
				user_tsc_khz, tsc_khz);

will again hit a #DE, no?

Even if KVM somehow makes it past that, kvm_guest_time_update() will put the vCPU
into an infinite request loop as get_cpu_tsc_khz() will always return 0 for modern
CPUs with a constant TSC:

  static unsigned long get_cpu_tsc_khz(void)
  {
	if (cpu_feature_enabled(X86_FEATURE_CONSTANT_TSC))
		return tsc_khz;    <======================== always zero
	else
		return __this_cpu_read(cpu_tsc_khz);
  }

And so this code will re-request KVM_REQ_CLOCK_UPDATE and the vCPU will hang.

	tgt_tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
	if (unlikely(tgt_tsc_hz == 0)) {
		preempt_enable();
		kvm_make_request(KVM_REQ_CLOCK_UPDATE, v);
		return 1;
	}