On Tue, Apr 24, 2018 at 10:19:27AM +0200, Paolo Bonzini wrote:
On 23/04/2018 23:05, Anthoine Bourgeois wrote:
- now = ktime_get();
- remaining = ktime_sub(apic->lapic_timer.target_expiration, now);
+ remaining = hrtimer_get_remaining(&apic->lapic_timer.timer);
I'm confused, how can this work when the preemption timer is in use
(vcpu->arch.apic->lapic_timer.hv_timer_in_use is true)?
I don't really know, this hunk is only a revert that works for me.
If you don't revert the whole patch, you should try and understand how
the hunks you revert interact with those that you leave in place!
I'm still seeking what is the root cause. My guest is the
target_expiration variable is mis compute sometimes.
Yes, that is likely.
In start_sw_period, the target_expiration is sometimes in the past (aka.
lesser than ktime_get()). Most of the time hrtimer_start is fast to call
the timer function, few microseconds, but sometimes it can takes
microseconds. Maybe a check like start_sw_tscdeadline does to expire the
timer immediately will be good.
On another way, I saw that target_expiration is sometimes in a future
farer than the next period (I compare target_expiration > now + period
in start_sw_period). Do you think it is a normal thing or
target_expiration should be adjust to avoid a timer miss ?
Anthoine
