From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBWXN-0004R8-Cw for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:49:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBWXM-0007Nt-2x for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:49:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBWXL-0007Ni-Jb for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:49:48 -0400 Date: Wed, 5 Oct 2011 15:49:42 -0300 From: Luiz Capitulino Message-ID: <20111005154942.1ee4e153@doriath> In-Reply-To: <4E8C9B9C.7090802@redhat.com> 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> <4E8C9289.1080408@redhat.com> <20111005143916.0557d2c5@doriath> <4E8C9B9C.7090802@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Avi Kivity Cc: Paolo Bonzini , Jan Kiszka , qemu-devel@nongnu.org On Wed, 05 Oct 2011 20:02:04 +0200 Avi Kivity wrote: > On 10/05/2011 07:39 PM, Luiz Capitulino wrote: > > On Wed, 05 Oct 2011 19:23:21 +0200 > > Avi Kivity wrote: > > > > > 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). > > > > It should be configurable at migration time I think. > > Why? autostart can easily be emulated by non-autostart, but not vice versa. What I meant is to give the user the choice to use. > > > 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. > > > > That's only one example. You mention another one above: if qemu stops > > itself twice, will the user be required to run 'cont' twice? > > Yes. That's how the user tells qemu it saw the two events and handled > both of them. Otherwise there is a race condition and an event goes > unhandled (or rather, it is handled while the guest is running instead > of stopped). Breaks compatibility. > > I'm not exactly against the semantics you're proposing, but they don't > > seem to fit today's qemu. > > Today's qemu is broken here. For me it's broken because it will abort() if you migrate a paused vm, for you it seems to be broken at the semantic level. We can fix the semantics without breaking compatibility.