Re: 2.6.27.5 guest boot failure using in-kernel PIT

[Eduardo Habkost <ehabkost@redhat.com>]

On Fri, Nov 21, 2008 at 02:39:22PM -0200, Eduardo Habkost wrote:
> On Fri, Nov 21, 2008 at 04:41:00PM +0100, Jan Kiszka wrote:
> > Eduardo Habkost wrote:
<snip>
> > > 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.

That's the case. From a probe on __pit_timer_fn.return:
19344471136382 timer_fn returning. timer expires now at: 19343448496177
19344475128359 timer_fn returning. timer expires now at: 19343449496025
19344479128694 timer_fn returning. timer expires now at: 19343450495873
19344483129394 timer_fn returning. timer expires now at: 19343451495721

The number at the beginning of the lines is ktime_get(). The timer
expiration time is on the past, but the kernel keeps triggering the
timer once every 4 ms.

-- 
Eduardo