From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Live migration locks up 3.2 guests in do_timer(ticks ~ 500000) Date: Wed, 12 Nov 2014 09:59:59 +0100 Message-ID: <5463218F.6020106@redhat.com> References: <20140908055416.GE23305@hydra.tuxags.com> <540D663E.2070905@redhat.com> <20140908155642.GF23305@hydra.tuxags.com> <540DD6E6.70409@redhat.com> <20140910065349.GM23305@hydra.tuxags.com> <20140915181441.GN23305@hydra.tuxags.com> <5417F801.20408@redhat.com> <20141027184216.GA29098@hydra.tuxags.com> <544F5C0A.1040504@redhat.com> <20141111195703.GF29098@hydra.tuxags.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35838 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752582AbaKLJAE (ORCPT ); Wed, 12 Nov 2014 04:00:04 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAC9035R025592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 12 Nov 2014 04:00:03 -0500 Received: from [10.36.112.47] (ovpn-112-47.ams2.redhat.com [10.36.112.47]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAC900AG025560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 12 Nov 2014 04:00:02 -0500 In-Reply-To: <20141111195703.GF29098@hydra.tuxags.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/11/2014 20:57, Matt Mullins wrote: > That seems to work great, yes. > > Looking through the commit history, I see: > kvmclock: Ensure time in migration never goes backward > kvmclock: Ensure proper env->tsc value for kvmclock_current_nsec calculation > > Assuming those are the right fixes for this issue, are they suitable to request > backported to distros' qemu 2.0 branches? The merge commit for them seemed to > indicate they were problematic at first. > > On second thought - I found the qemu-devel threads about reverting them in the > 2.1 timeframe, so I'm going to do a little more research before I start trying > to suggest how to fix for existing install-base. The right commits are de9d61e83d43be9069e6646fa9d57a3f47779d28 317b0a6d8ba44e9bf8f9c3dbd776c4536843d82c 9a48bcd1b82494671c111109b0eefdb882581499 which are similar but not equivalent to the two commits you found. They should be in 2.1.3 if there will be one, and they are appropriate for backporting to 2.0. Thanks for confirming that they fix your problem! Paolo