From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3vVj-0001eJ-RP for qemu-devel@nongnu.org; Thu, 16 Jan 2014 17:34:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3vVW-0004uO-FS for qemu-devel@nongnu.org; Thu, 16 Jan 2014 17:34:03 -0500 Received: from mx.beyond.pl ([92.43.117.49]:51022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3vVW-0004ss-8u for qemu-devel@nongnu.org; Thu, 16 Jan 2014 17:33:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mx.beyond.pl (Postfix) with ESMTP id D3AE31E5E for ; Thu, 16 Jan 2014 23:33:47 +0100 (CET) Received: from mx.beyond.pl ([127.0.0.1]) by localhost (mw.beyond.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7PwdaF07riI for ; Thu, 16 Jan 2014 23:33:47 +0100 (CET) Received: from [192.168.1.121] (src75-20.unii.maverick.com.pl [194.187.75.20]) (Authenticated sender: m.gibula@beyond.pl) by mx.beyond.pl (Postfix) with ESMTPSA id 703031CF2 for ; Thu, 16 Jan 2014 23:33:47 +0100 (CET) Message-ID: <52D85E48.8030403@beyond.pl> Date: Thu, 16 Jan 2014 23:33:44 +0100 From: =?UTF-8?B?TWFyY2luIEdpYnXFgmE=?= MIME-Version: 1.0 References: CALFpzo4pYYijB9PcXL6Hr2Vf6nPW2vy7UjKkR8YN+xEuvZv3PA@mail.gmail.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] troubleshooting live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > I tried -no-hpet, was still able to replicate the 'lapic' issue. I > find it interesting that I can only trigger it if the vm has been > running awhile. Hi, I've seen identical crashes with live migration in our environment. It looks identical - VM has to be idle for some time and after migration CPU is at 100% and VM is dead. All migration happens between same hardware. I don't think I've ever had Windows guest crashing like this and I think this is somehow related to kvmclock. I've tried to debug qemu guest process and from I can tell, its kernel is busy looping in some time management related functions. Could you try to reproduce this issue with -no-kvmclock? Our testing environment is currently offline so I can't test it myself. We also use 3.10 kernel (though 3.8 wasn't working either) and strugled with this issue with qemu 1.4, 1.5 and 1.6. Didn't test 1.7. Also we're using AMD CPUs, so it seems to be platform independend. -- mg