From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nd67M-0007Sa-7s for qemu-devel@nongnu.org; Thu, 04 Feb 2010 13:07:52 -0500 Received: from [199.232.76.173] (port=38015 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nd67L-0007Rf-OO for qemu-devel@nongnu.org; Thu, 04 Feb 2010 13:07:51 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nd67J-00040W-TN for qemu-devel@nongnu.org; Thu, 04 Feb 2010 13:07:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49497) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nd67J-00040A-C6 for qemu-devel@nongnu.org; Thu, 04 Feb 2010 13:07:49 -0500 Date: Thu, 4 Feb 2010 16:05:55 -0200 From: Marcelo Tosatti Message-ID: <20100204180555.GA3861@amt.cnet> References: <372238c800e0d57815f472502fdf78e53463bbb6.1265232579.git.jan.kiszka@siemens.com> <20100203234929.GA11012@amt.cnet> <4B6A15EE.4050501@web.de> <20100204130038.GA15671@amt.cnet> <4B6AE1E6.9040805@siemens.com> <4B6AEAB8.3030509@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6AEAB8.3030509@siemens.com> Subject: [Qemu-devel] Re: [PATCH 4/4] KVM: Rework of guest debug state writing List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity On Thu, Feb 04, 2010 at 04:41:44PM +0100, Jan Kiszka wrote: > Jan Kiszka wrote: > > Marcelo Tosatti wrote: > >> On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote: > >>> Marcelo Tosatti wrote: > >>>> On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote: > >>>>> So far we synchronized any dirty VCPU state back into the kernel before > >>>>> updating the guest debug state. This was a tribute to a deficit in x86 > >>>>> kernels before 2.6.33. But as this is an arch-dependent issue, it is > >>>>> better handle in the x86 part of KVM and remove the writeback point for > >>>>> generic code. > >>>> Jan, > >>>> > >>>> This patch breaks migration. > >>> Can you elaborate what you did? I can't reproduce, and I do not see any > >>> conceptual issue (given that guest debugging conflicts with migration > >>> anyway). > >> kvm-autotest fails (migration only, install is ok, both Linux and Win > >> guests). Not sure why, perhaps the unconditional KVM_SET_GUEST_DEBUG > >> corrupts state somehow? > >> > >> Tested with io thread enabled. > > > > That's this default-off thing, so... OK, confirmed, investigating. > > > > Heisenbug: It first also popped up (in form of a frozen migration > target) after removing this patch, but now it's totally unreproducible, > whatever patch I apply or revert from my series. Base is current master. > > I tend to think there is a hidden issue of iothread vs. migration, > unrelated to this patch. Probably many :) Do you have c5f32c99c6855d466737daf1cd262e7e92062f87 (from qemu-kvm.git uq/master) in? With kvm-autotest the failure is not sporadic (and the above commit applied): with KVM_SET_GUEST_DEBUG in arch_put_regs all migration tests fail, without, all of them succeed. So env->kvm_guest_debug has been zeroed by cpu_x86_init, which means the writeback via KVM_SET_GUEST_DEBUG does almost nothing. It does get_rflags and set_rflags in the kernel. Test box is off, but the synchronous writeback via qemu_system_reset in main, after machine and vcpu thread initialization, might be problematic. But it would be nice to understand this. Unrelated to this problem, won't put_vcpu_events, which is executed after KVM_SET_GUEST_DEBUG, overwrite any queued debug exceptions?