From patchwork Tue Jan 20 11:20:41 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sheng Yang X-Patchwork-Id: 3271 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 n0KBGGAA012252 for ; Tue, 20 Jan 2009 03:16:16 -0800 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758106AbZATLUr (ORCPT ); Tue, 20 Jan 2009 06:20:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758111AbZATLUr (ORCPT ); Tue, 20 Jan 2009 06:20:47 -0500 Received: from mga09.intel.com ([134.134.136.24]:19572 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758106AbZATLUp (ORCPT ); Tue, 20 Jan 2009 06:20:45 -0500 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 20 Jan 2009 03:12:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,295,1231142400"; d="scan'208";a="379895257" Received: from syang10-desktop.sh.intel.com (HELO syang10-desktop.localnet) ([10.239.13.29]) by orsmga002.jf.intel.com with ESMTP; 20 Jan 2009 03:19:03 -0800 From: Sheng Yang Organization: Intel Opensource Technology Center To: Alexander Graf Subject: Re: [PATCH] Fix almost infinite loop in APIC Date: Tue, 20 Jan 2009 19:20:41 +0800 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; x86_64; ; ) Cc: Marcelo Tosatti , kvm@vger.kernel.org, avi@redhat.com, Kevin Wolf References: <1231432566-9864-1-git-send-email-agraf@suse.de> <20090116050143.GA13032@amt.cnet> <4975AA51.2060705@suse.de> In-Reply-To: <4975AA51.2060705@suse.de> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901201920.42519.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tuesday 20 January 2009 18:41:21 Alexander Graf wrote: > Marcelo Tosatti wrote: > > On Thu, Jan 15, 2009 at 03:20:06PM +0800, Sheng Yang wrote: > >>> + * Since reinjection is not rate-limited, use the delay > >>> + * to inject the last interrupt as an estimate. > >>> + */ > >>> + if (unlikely(atomic_read(&apic->timer.pending) > 0)) { > >>> + remaining = apic->timer.injection_delay; > >>> + if (ktime_to_ns(remaining) > apic->timer.period) > >>> + remaining = ns_to_ktime(apic->timer.period); > >>> + } else > >>> + remaining = hrtimer_expires_remaining(&apic->timer.dev); > >> > >> A little doubt... > >> > >> A: time_fire > >> B: intr_post > >> C: read TMCCT > >> > >> The sequence can be ABC or ACB. > >> > >> injection_delay = time(B) - time(A) > >> > >> So it didn't count time from read TMCCT... And guest get interrupt at > >> time(B), not quite understand why time(B) - time(A) matters here... > > > > Its an estimate of the delay it takes to inject an interrupt to the > > guest once fired. Its only used if there have been accumulated ones, so > > ACB sequence with pending=0 will use hrtimer_expires_remaining(). > > > >> I think the reasonable here means, this interval is usable later after > >> the accumulated interrupts are injected. From this point of view, I > >> think current solution is reasonable. It just assume the delayed > >> interrupts have been injected. > >> > >> However, seriously, any value here is wrong, no elegant one. > > > > I agree. > > > >> But I still prefer to the current solution... > > > > Why? The proposed version is smaller and simpler than the current > > one IMO, and also not vulnerable to whatever bug is causing now < > > last_update. > > > > And more precise, since the current scheme uses interrupt injection time > > as if it was "count-down restart" time, which is not true. > > > >> And here is not the really problem for now I think. The current > >> mechanism is mostly OK, but where is the bug... We have either have a > >> simple fix(e.g. if now < last_update, then return 0) or dig into it. Did > >> it worth a try? Anyway, it would return a buggy result if we have > >> pending interrupts... > > > > The overflow calculation is not necessary as discussed. Alexander, can > > you please try the following? Sheng, do you have any other suggestion to > > test? > > > > /proc/timer_list output of the host when ESX is running too. > > Sorry for the late reply. Here's the dmesg output and /proc/timer_list > after the issue occured. I left the warning message in that I put there > in case the value is too high: > > 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 */ > > > > start_apic_timer: bus cycle is 1ns, now 0x00039a6f377cfbc4, timer > initial count 0x186a0, period 100000ns, expire @ 0x00039a6f377e8264. > start_apic_timer: bus cycle is 1ns, now 0x00039a6f3a7b5aef, timer > initial count 0x203a0, period 132000ns, expire @ 0x00039a6f3a7d5e8f. > last_update = 1014860818546063 now = 1014860818426085 > rec[47] when=1014860811948512 last_update=1014860812078063 pend=0 > rec[46] when=1014860818417773 last_update=1014860818546063 pend=0 > rec[45] when=1014860818285454 last_update=1014860818414063 pend=0 > rec[44] when=1014860818153119 last_update=1014860818282063 pend=0 > rec[43] when=1014860818021746 last_update=1014860818150063 pend=0 > rec[42] when=1014860817889326 last_update=1014860818018063 pend=0 > rec[41] when=1014860817757297 last_update=1014860817886063 pend=0 > rec[40] when=1014860817625682 last_update=1014860817754063 pend=0 > rec[39] when=1014860817492484 last_update=1014860817622063 pend=0 > rec[38] when=1014860817360531 last_update=1014860817490063 pend=0 > rec[37] when=1014860817228489 last_update=1014860817358063 pend=0 > rec[36] when=1014860817101250 last_update=1014860817226063 pend=0 > rec[35] when=1014860816964378 last_update=1014860817094063 pend=0 > rec[34] when=1014860816832459 last_update=1014860816962063 pend=0 > rec[33] when=1014860816700514 last_update=1014860816830063 pend=0 > rec[32] when=1014860816568558 last_update=1014860816698063 pend=0 > rec[31] when=1014860816436510 last_update=1014860816566063 pend=0 > rec[30] when=1014860816305079 last_update=1014860816434063 pend=0 > rec[29] when=1014860816172560 last_update=1014860816302063 pend=0 > rec[28] when=1014860816040449 last_update=1014860816170063 pend=0 > rec[27] when=1014860815908500 last_update=1014860816038063 pend=0 > rec[26] when=1014860815776451 last_update=1014860815906063 pend=0 > rec[25] when=1014860815644499 last_update=1014860815774063 pend=0 > rec[24] when=1014860815513100 last_update=1014860815642063 pend=0 > rec[23] when=1014860815380476 last_update=1014860815510063 pend=0 > rec[22] when=1014860815248609 last_update=1014860815378063 pend=0 > rec[21] when=1014860815116494 last_update=1014860815246063 pend=0 > rec[20] when=1014860814984441 last_update=1014860815114063 pend=0 > rec[19] when=1014860814852498 last_update=1014860814982063 pend=0 > rec[18] when=1014860814721082 last_update=1014860814850063 pend=0 > rec[17] when=1014860814588467 last_update=1014860814718063 pend=0 > rec[16] when=1014860814456530 last_update=1014860814586063 pend=0 > rec[15] when=1014860814324452 last_update=1014860814454063 pend=0 > rec[14] when=1014860814192601 last_update=1014860814322063 pend=0 > rec[13] when=1014860814060489 last_update=1014860814190063 pend=0 > rec[12] when=1014860813928546 last_update=1014860814058063 pend=0 > rec[11] when=1014860813797571 last_update=1014860813926063 pend=0 > rec[10] when=1014860813664475 last_update=1014860813794063 pend=0 > rec[9] when=1014860813532520 last_update=1014860813662063 pend=0 > rec[8] when=1014860813400463 last_update=1014860813530063 pend=0 > rec[7] when=1014860813268519 last_update=1014860813398063 pend=0 > rec[6] when=1014860813136452 last_update=1014860813266063 pend=0 > rec[5] when=1014860813007312 last_update=1014860813134063 pend=0 > rec[4] when=1014860812872314 last_update=1014860813002063 pend=0 > rec[3] when=1014860812740791 last_update=1014860812870063 pend=0 > rec[2] when=1014860812652998 last_update=1014860812738063 pend=0 > rec[1] when=1014860812476526 last_update=1014860812606063 pend=0 > rec[0] when=1014860812344635 last_update=1014860812474063 pend=0 > rec[49] when=1014860812213098 last_update=1014860812342063 pend=0 > rec[48] when=1014860812080466 last_update=1014860812210063 pend=0 > LAPIC: Too high counter_passed value: 0x7ffffffffffe2b55 | > 0x7ffffffffffe2b55 (0x7ffffffffffe2b55) | 0x39b02b29428e5 (0x39b02b295fd8f) > start_apic_timer: bus cycle is 1ns, now 0x00039b02b2998ada, timer > initial count 0x8400, period 33792ns, expire @ 0x00039b02b29a0eda. > Thanks, Alex! When update time of last_update is 0x39B02B29428E5, and the start_apic_timer at 0x00039b02b2998ada, the delta is 0x561F5 = 352,757, very close. Looks like a window here?: > static void start_apic_timer(struct kvm_lapic *apic) > { > ktime_t now = apic->timer.dev.base->get_time(); > > apic->timer.last_update = now; [window?] > > apic->timer.period = apic_get_reg(apic, APIC_TMICT) * > APIC_BUS_CYCLE_NS * apic->timer.divide_count; > atomic_set(&apic->timer.pending, 0); > > if (!apic->timer.period) > return; > > hrtimer_start(&apic->timer.dev, > ktime_add_ns(now, apic->timer.period), > HRTIMER_MODE_ABS); > > apic_debug("%s: bus cycle is %" PRId64 "ns, now 0x%016" > PRIx64 ", " > "timer initial count 0x%x, period %lldns, " > "expire @ 0x%016" PRIx64 ".\n", __func__, > APIC_BUS_CYCLE_NS, ktime_to_ns(now), > apic_get_reg(apic, APIC_TMICT), > apic->timer.period, > ktime_to_ns(ktime_add_ns(now, > apic->timer.period))); > } Looks like due to the period is reduced, but the last_update use old value and got just updated... But guest vcpu B program vcpu A's lapic? Or intr_post of vcpu B happened at vcpu A? Both seems unreasonable... Alex, can you help to add another line above to confirm the problem? e.g. Also add a similar one at the beginning of print_last_update_record(). Thanks! (And thanks for Marcelo's excellent debug patch! :) ) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index afac68c..15f8ed5 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -653,6 +653,8 @@ static void start_apic_timer(struct kvm_lapic *apic) { ktime_t now = apic->timer.dev.base->get_time(); + printk("enter start_apic_timer! vcpu %d\n", apic->vcpu->vcpu_id); + apic->timer.last_update = now; apic->timer.period = apic_get_reg(apic, APIC_TMICT) *