While booting Linux in VMware ESX, I encountered a strange effect in the in-kernel lapic implementation: time went backwards!
While this should never occur, because of that the while loop that is done after the invalid calculations caused my host system to hang. In order to make debugging easier, let's replace this as suggested with a modulo function and not run into the danger of looping forever. To replace the nice hint this bug gave me that the values are broken, I added a printk message so people encountering this can at least see that something is fishy. Of course, the real issue needs to be fixed as well! I'm open to ideas why now < last_update! (Thanks to Kevin for his help in debugging this) Signed-off-by: Alexander Graf <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> --- arch/x86/kvm/lapic.c | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index afac68c..737217b 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -539,19 +539,20 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic) counter_passed = div64_u64(ktime_to_ns(passed), (APIC_BUS_CYCLE_NS * apic->timer.divide_count)); + if (counter_passed > 0x7f00000000000000) { + /* If we're in here we probably encountered a bug! */ + printk(KERN_INFO "LAPIC: Too high counter_passed value: " + "0x%lx | 0x%lx (0x%lx) | 0x%lx (0x%lx)\n", + counter_passed, ktime_to_ns(passed), passed, + now.tv64, apic->timer.last_update.tv64); + } + if (counter_passed > tmcct) { if (unlikely(!apic_lvtt_period(apic))) { /* one-shot timers stick at 0 until reset */ tmcct = 0; } else { - /* - * periodic timers reset to APIC_TMICT when they - * hit 0. The while loop simulates this happening N - * times. (counter_passed %= tmcct) would also work, - * but might be slower or not work on 32-bit?? - */ - while (counter_passed > tmcct) - counter_passed -= tmcct; + counter_passed %= (u64)tmcct; tmcct -= counter_passed; } } else { -- 1.6.0.2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
