From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: Re: 2.6.27.5 guest boot failure using in-kernel PIT Date: Fri, 21 Nov 2008 14:39:22 -0200 Message-ID: <20081121163922.GG30825@blackpad> References: <20081120142253.GA30825@blackpad> <20081120220517.GB30825@blackpad> <49266950.40200@web.de> <20081121131741.GC30825@blackpad> <4926D68C.8050401@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40555 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbYKUQjx (ORCPT ); Fri, 21 Nov 2008 11:39:53 -0500 Content-Disposition: inline In-Reply-To: <4926D68C.8050401@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Nov 21, 2008 at 04:41:00PM +0100, Jan Kiszka wrote: > Eduardo Habkost wrote: > > On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote: > >> Eduardo Habkost wrote: > >>> On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > >>>> Hi, > >>>> > >>>> When using a kvm.git kernel as host, I am getting guest boot failures > >>>> when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > >>>> stops booting at: > >>>> > >>>> ENABLING IO-APIC IRQs > >>>> ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 > >>>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC > >>>> ...trying to set up timer (IRQ0) through the 8259A ... > >>>> ..... (found apic 0 pin 0) ... > >>>> ....... failed. > >>>> ...trying to set up timer as Virtual Wire IRQ... > >>>> ..... failed. > >>>> ...trying to set up timer as ExtINT IRQ... > >>> I've just found out this problem happens because the guest has HZ=1000 > >>> and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > >>> > >>> With this setup, the host is not managing to inject enough timer > >>> interrupts during the mdelay() loop on timer_irq_works(). > >>> > >> Interesting, and plausible. > >> > >> My observation so far is a sporadic test failure, often correlating with > >> some raised host OS load. I'm running a high-res kernel, but that cannot > >> prevent that this only 10 ticks long loop of the guest may obtain too > >> few CPU cycles to handle enough of them once in a while (IIRC, it needs > >> 4 out of the 10 ticks to declare the timer routing functional). > >> > >> Maybe Gleb's anti-coalesce patches for the PIC can also deal with your > >> timer resolution conflict. At least worth a try... > > > > Aren't Gleb patches for the userspace PIT? > > Yeah, they are, so you won't benefit from them for in-kernel cases. But > with in-kernel emulation just the probability of coalesced ticks is a > bit lower, they cannot be avoided either. > > > I am seeing the problem here > > when using the in-kernel PIT, but (surprisingly) my setup works when > > using -no-kvm-pit. > > Weird, makes no sense to me as well ATM. The qemu PIT seems to calculate the timeout for its timer as a function of the time where the PIT timer was set up (count_load_time) and the last timer set up (next_transition_time), without looking at the current time. After missing some ticks and getting the timer triggered late, it will set up a lot of "trigger on the past" timers before the guest finished the mdelay() loop. The in-kernel PIT seems to try to do the same thing (it just calls hrtimer_add_expires_ns() on the timer), but maybe the behaviour of the kernel timers is different of the qemu timers when a timer is set up to be triggered on the past. On my host-HZ=250 guest-HZ=1000 setup, it was incrementing pit_timer.pending only once every 4 milliseconds. -- Eduardo