On 30/01/18 12:42, Christoffer Dall wrote: > After the recently introduced support for level-triggered mapped > interrupt, I accidentally left the VCPU thread busily going back and > forward between the guest and the hypervisor whenever the guest was > blocking, because I would always incorrectly report that a timer > interrupt was pending. > > This is because the timer->irq.level field is not valid for mapped > interrupts, where we offload the level state to the hardware, and as a > result this field is always true. > > Luckily the problem can be relatively easily solved by not checking the > cached signal state of either timer in kvm_timer_should_fire() but > instead compute the timer state on the fly, which we do already if the > cached signal state wasn't high. In fact, the only reason for checking > the cached signal state was a tiny optimization which would only be > potentially faster when the polling loop detects a pending timer > interrupt, which is quite unlikely. > > Instead of duplicating the logic from kvm_arch_timer_handler(), we > enlighten kvm_timer_should_fire() to report something valid when the > timer state is loaded onto the hardware. We can then call this from > kvm_arch_timer_handler() as well and avoid the call to > __timer_snapshot_state() in kvm_arch_timer_get_input_level(). > > Reported-by: Tomasz Nowicki <tn@xxxxxxxxxxxx> > Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxxxxx> Reviewed-by: Marc Zyngier <marc.zyngier@xxxxxxx> M. -- Jazz is not dead. It just smells funny...
