From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu24c-0003uH-09 for qemu-devel@nongnu.org; Wed, 04 Nov 2015 12:42:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zu24X-0002bK-N1 for qemu-devel@nongnu.org; Wed, 04 Nov 2015 12:42:13 -0500 Received: from mail-qg0-x22b.google.com ([2607:f8b0:400d:c04::22b]:35996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu24X-0002b9-GZ for qemu-devel@nongnu.org; Wed, 04 Nov 2015 12:42:09 -0500 Received: by qgad10 with SMTP id d10so46324918qga.3 for ; Wed, 04 Nov 2015 09:42:08 -0800 (PST) Date: Wed, 4 Nov 2015 12:42:02 -0500 From: Kevin O'Connor Message-ID: <20151104174201.GA17784@morn.lan> References: <8E78D212B8C25246BE4CE7EA0E645FE5291A08@SZXEMI504-MBS.china.huawei.com> <563955D4.7080000@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <563955D4.7080000@huawei.com> Subject: Re: [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gonglei Cc: "Huangweidong (C)" , "wangxin (U)" , seabios@seabios.org, "Xulei (Stone, Euler)" , qemu-devel On Wed, Nov 04, 2015 at 08:48:20AM +0800, Gonglei wrote: > On 2015/11/3 14:58, Xulei (Stone, Euler) wrote: > > On qemu-kvm platform, when I reset a VM through "virsh reset", and coincidently > > the VM is in process of internal rebooting at the same time. Then the VM will > > not be successfully reseted any more due to the reset reentrancy. I found: > > (1)SeaBios try to shutdown the VM after reseting it failed by apm_shutdown(). > > However, apm_shutdown() does not work on qemu-kvm platform; > > (2)I add 1s sleep in qemu_prep_reset(), then continuously reset the VM twice, > > aforementioned case must happen. So, the problem occurs when issuing a second reset before the first reset completes? > > This patch fixes this issue by letting the VM always execute the reboot > > routing while a reenrancy happenes instead of attempting apm_shutdown on > > qemu-kvm platform. The reason for the HaveAttemptedReboot check is to work around old versions of KVM that unexpectedly map the same memory to both 0xf0000 and 0xffff0000. So, it does not make sense to wrap the check in a !runningOnKVM() block as that disables the only reason for the check. I'm surprised you would see the above on a recent qemu/kvm though - as on a newer KVM I think the second reset would have to happen after HaveAttemptedReboot is set and prior to the memcpy in qemu_prep_reset() completing. Can you verify your KVM version? -Kevin