2016-05-22 9:23 GMT+08:00 Wanpeng Li <kernellwp@xxxxxxxxx>: > 2016-05-20 19:47 GMT+08:00 Alan Jenkins <alan.christopher.jenkins@xxxxxxxxx>: >> Hi >> >> I'm getting a hard lockup in wait_lapic_expire(). I'm not certain why, >> and it didn't seem to reproduce on a second setup. However I found a >> suspect in the code for TSC deadline timers. Maybe someone is interested >> in my analysis. >> >> If a guest has a TSC deadline timer set, it's not re-done when the TSC >> is adjusted, and will fire at the wrong time. The hrtimer used for >> emulation is not being recalculated. If the TSC was set _backwards_, I >> think it could trigger a lockup in wait_lapic_expire(). This function is >> a busy-loop optimization, which could be tricked into busy-looping for >> too long. The expected busy-wait is `lapic_timer_advance_ns`, which >> defaults to 0 (I haven't changed it). > > The default clockevent device for hrtimer is lapic, and tsc works as a > clocksource device, even if tsc in guest is backwards/adjusted, > clockevent device is not influenced and work normally I think, so we > just need to keep clockevent device can fire asap when it expires. How > about someting like below(I can't reproduce your bug and just can send > out a formal patch after your confirm): > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index bbb5b28..02a21d3 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -1310,7 +1310,7 @@ void wait_lapic_expire(struct kvm_vcpu *vcpu) > > /* __delay is delay_tsc whenever the hardware has TSC, thus always. */ > if (guest_tsc < tsc_deadline) > - __delay(tsc_deadline - guest_tsc); > + __delay(max((tsc_deadline - guest_tsc), > lapic_timer_advance_ns)); > } s/max/min -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
