From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBVBp-00049y-Ln for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:23:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBVBo-0008DC-4h for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:23:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBVBn-0008Cn-M4 for qemu-devel@nongnu.org; Wed, 05 Oct 2011 13:23:28 -0400 Message-ID: <4E8C9289.1080408@redhat.com> Date: Wed, 05 Oct 2011 19:23:21 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1317729885-17534-1-git-send-email-pbonzini@redhat.com> <20111005113707.5312f98b@doriath> <4E8C7B1C.2020808@redhat.com> <4E8C8656.3040706@web.de> <4E8C87DF.5080201@redhat.com> <20111005140222.11294000@doriath> In-Reply-To: <20111005140222.11294000@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Paolo Bonzini , Jan Kiszka , qemu-devel@nongnu.org On 10/05/2011 07:02 PM, Luiz Capitulino wrote: > On Wed, 05 Oct 2011 18:37:51 +0200 > Avi Kivity wrote: > > > On 10/05/2011 06:31 PM, Jan Kiszka wrote: > > > >> > > > > > > > > vm_start() should be symmetric with vm_stop(). That is, if a piece of > > > > code wants to execute with vcpus stopped, it should just run inside a > > > > stop/start pair. > > > > > > > > The only confusion can come from the user, if he sees multiple stop > > > > events and expects that just one cont will continue the vm. For the > > > > machine monitor, we should just document that the you have to issue one > > > > cont for every stop event you see (plus any stops you issue). It's not > > > > unnatural - the code that handles a stop_due_to_enospace can work to fix > > > > the error and issue a cont, disregarding any other stops in progress > > > > (due to a user pressing the stop button, or migration, or cpu hotplug, > > > > or whatever). For the human monitor, it's not so intuitive, but the > > > > situation is so rare we can just rely on the user to issue cont again. > > > > > > Making this kind of user-visible change would be a bad idea. > > > > The current situation is a bad idea. > > Let's take the migration use-case as an example (ie. the user stops the VM > before performing the migration). Today, if migration fails, > migrate_fd_put_ready() will call vm_start() which will put the VM to > run again. > > But if we implement the ref count idea, then vm_start() will just "unlock" > migrate_fd_put_ready()'s own call to vm_stop(), that's, the user stop will > remain and the user is required to do a 'cont'. > > I'd probably agree that that's the ideal semantics, but chances are we're > going to break qmp clients here. There are two questions here. Is this autostart desirable? (IMO no, but haven't given it much thought). If yes, we should provide it somehow. If not, we should default to providing it, but switch to non-autostart if a newer client indicates it understands the new semantics. -- error compiling committee.c: too many arguments to function