From: Sean Christopherson <seanjc@google.com>
To: Peng Hao <flyingpenghao@gmail.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Guard against division by zero in adjust_lapic_timer_advance()
Date: Fri, 9 Oct 2026 13:35:57 -0700 [thread overview]
Message-ID: <aslQLXcK1VXSkrVo@google.com> (raw)
In-Reply-To: <20261008090037.86931-1-flyingpeng@tencent.com>
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.
vcpu->arch.virtual_tsc_{shift,mult} will also be left as zero (to avoid #DE there
as well):
/* tsc_khz can be zero if TSC calibration fails */
if (user_tsc_khz == 0) {
/* set tsc_scaling_ratio to a safe value */
kvm_vcpu_write_tsc_multiplier(vcpu, kvm_caps.default_tsc_scaling_ratio);
return -1;
}
/* Compute a scale to convert nanoseconds in TSC cycles */
kvm_get_time_scale(user_tsc_khz * 1000LL, NSEC_PER_SEC,
&vcpu->arch.virtual_tsc_shift,
&vcpu->arch.virtual_tsc_mult);
and so nsec_to_cycles() will always return zero due to multiplying by zero. That
means things like the APIC timer will always fire immediately:
apic->lapic_timer.tscdeadline = kvm_read_l1_tsc(apic->vcpu, tscl) +
nsec_to_cycles(apic->vcpu, deadline);
The first instance of this goes back to 03ba32cae66e ("VMX: x86: handle host TSC
calibration failure"), and every "fix" since then has been to avoid #DE.
> +
> /* too early */
> if (advance_expire_delta < 0) {
> ns = -advance_expire_delta * 1000000ULL;
> --
> 2.43.7
>
next prev parent reply other threads:[~2026-10-09 20:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 9:00 [PATCH] KVM: x86: Guard against division by zero in adjust_lapic_timer_advance() Peng Hao
2026-10-08 9:15 ` sashiko-bot
2026-10-09 20:35 ` Sean Christopherson [this message]
2026-10-10 8:59 ` Hao Peng
2026-10-12 13:11 ` Sean Christopherson
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=aslQLXcK1VXSkrVo@google.com \
--to=seanjc@google.com \
--cc=flyingpenghao@gmail.com \
--cc=kvm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.