From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M2U8i-0005Zr-DK for qemu-devel@nongnu.org; Fri, 08 May 2009 13:45:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M2U8d-0005YQ-PG for qemu-devel@nongnu.org; Fri, 08 May 2009 13:45:40 -0400 Received: from [199.232.76.173] (port=57975 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M2U8d-0005YN-If for qemu-devel@nongnu.org; Fri, 08 May 2009 13:45:35 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:51145) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M2U8d-0005UT-62 for qemu-devel@nongnu.org; Fri, 08 May 2009 13:45:35 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n48Hlib9006469 for ; Fri, 8 May 2009 13:47:44 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n48HjY9j134572 for ; Fri, 8 May 2009 13:45:34 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n48HjXTV001376 for ; Fri, 8 May 2009 13:45:34 -0400 Date: Fri, 8 May 2009 12:45:33 -0500 From: Ryan Harper Message-ID: <20090508174533.GF3233@us.ibm.com> References: <1241801561-11441-1-git-send-email-ryanh@us.ibm.com> <4A046503.8050209@us.ibm.com> <20090508171305.GC3233@us.ibm.com> <4A046E09.6080101@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A046E09.6080101@us.ibm.com> Subject: [Qemu-devel] Re: [PATCH] Add monitor command for system_reboot List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Ryan Harper , "qemu-devel@nongnu.org" * Anthony Liguori [2009-05-08 12:38]: > Ryan Harper wrote: > >* Anthony Liguori [2009-05-08 12:00]: > > > >>If qemu_shutdown_requested(), then we'll immediately shutdown the system. > >> > > > >Right, but this request happens after we've sent the ACPI powerdown > >event. After we've done the powerdown (acpi aware guests can do a > >shutdown), instead of then calling shutdown, which exits, we call > >reset. > > > > I'm saying, semantically, if you call 'qemu_shutdown_requested()', if it > returns 1, it means, immediately shutdown the VM--regardless of where > it's called. > > The semantics of qemu_reboot_requested() are, if it returns 1, then only > when you see an ACPI soft power off, reset the VM. It's that difference > in semantics that I think could lead to confusion. well, I think this is where we're missing each other. I figured if the users requested a reboot, that we also trigger the powerdown, and that's what I'm doing. If in the monitor you issue system_reboot, I'm triggering a powerdown automatically. Are you saying you want the users to do, system_reset, and then system_powerdown in their own? And if that is the case, I can see why you're asking to maintain the state of the flag. IMO, I think triggering the powerdown from the reboot call makes sense. > >>And I think this also needs to be stored as part of the savevm state for > >>hw/acpi.c. If you do a system_reboot followed by an immediate live > >>migration, without the savevm handler, the VM will shutdown completely > >>after the migration instead of rebooting as expected. > >> > > > >Would it? I don't see that we are saving powerdown|shutdown|reset > >request flags? Sounds like all of those flags need to be in the save > >state, and separate patch IMHO. > > > > No, they don't. > > A qemu_powerdown_request() call happens from the monitor. This is to > allow a graceful shutdown (as opposed to exiting from the monitor). > This will trigger the TCG loop to immediately exit. The state doesn't > need to be saved because you cannot do a migration in between when > qemu_powerdown_request() is called and when the shutdown actually happens. Sure, and I don't see why reboot semantics would be any different unless you thinking about the above case I think you might be meaning. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com