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 -- 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
