Re: 2.6.27.5 guest boot failure using in-kernel PIT

[Eduardo Habkost <ehabkost@redhat.com>]

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