From patchwork Thu Jan 8 16:36:06 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Graf X-Patchwork-Id: 1389 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n08GWVE7011461 for ; Thu, 8 Jan 2009 08:32:32 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752749AbZAHQgJ (ORCPT ); Thu, 8 Jan 2009 11:36:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753087AbZAHQgI (ORCPT ); Thu, 8 Jan 2009 11:36:08 -0500 Received: from cantor.suse.de ([195.135.220.2]:52352 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752749AbZAHQgH (ORCPT ); Thu, 8 Jan 2009 11:36:07 -0500 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id C1B07459CF; Thu, 8 Jan 2009 17:36:06 +0100 (CET) From: Alexander Graf To: kvm@vger.kernel.org Cc: avi@redhat.com, Kevin Wolf Subject: [PATCH] Fix almost infinite loop in APIC Date: Thu, 8 Jan 2009 17:36:06 +0100 Message-Id: <1231432566-9864-1-git-send-email-agraf@suse.de> X-Mailer: git-send-email 1.6.0.2 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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 Signed-off-by: Kevin Wolf --- 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 {