On Tue, 2022-03-08 at 17:49 +0100, Paolo Bonzini wrote: > On 3/8/22 17:41, David Woodhouse wrote: > > Thanks. I've literally just a couple of minutes ago finished diagnosing > > a sporadic live migration / live update bug which seems to happen > > because adding an hrtimer in the past*sometimes* seems not to work, > > although it always worked in my dev testing. > > > > Incremental diff to the 'oneshot timers' patch looks like the first > > hunk of this. I'm also pondering the second hunk which actively > > *cancels* the pending timer on serialization. > > Hmm, why so? Don't know yet. But as I added the save/restore support to Joao's patch I had *assumed* that it would fail when the delta was negative, and was kind of surprised when it worked in the first place. So I'm sticking with "Don't Do That Then" as my initial response to fix it. > > Do you want a repost, or a proper incremental patch on top of kvm/queue > > when it becomes visible? > > kvm/queue is rebased routinely, so I'll just squash (only the first > hunk, methinks). Got a testcase, though? That might be better as a > separate patch. My test case right now is to run 'while true; time sleep 1; done' in the guest while I repeatedly kexec / live update the host. After a kexec, the deadline for the timer is past, and that's why it ends up getting restored with a negative delta. After a *few* cycles of this it usually ends up with the timer callback never triggering. I'll stick a negative delta into the KVM selftest included in the patch series, instead of the nice polite '100ms in the future' that it uses at the moment. That ought to trigger it too, and I can instrument the hrtimer code to work out what's going on. Either way, I think 'Don't Do That Then' will continue to be the right answer :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
