From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBlup-00038D-VX for qemu-devel@nongnu.org; Thu, 06 Oct 2011 07:15:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBluo-0003yU-TV for qemu-devel@nongnu.org; Thu, 06 Oct 2011 07:15:03 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:59564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBluo-0003y3-Ig for qemu-devel@nongnu.org; Thu, 06 Oct 2011 07:15:02 -0400 Received: by bkbzv15 with SMTP id zv15so3282823bkb.4 for ; Thu, 06 Oct 2011 04:15:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E8D8DB0.1050106@redhat.com> Date: Thu, 06 Oct 2011 13:14:56 +0200 From: Paolo Bonzini 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> <4E8C9289.1080408@redhat.com> <20111005143916.0557d2c5@doriath> <4E8C9B9C.7090802@redhat.com> <20111005154942.1ee4e153@doriath> <20111005155026.62fa9071@doriath> In-Reply-To: <20111005155026.62fa9071@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: Jan Kiszka , Avi Kivity , qemu-devel@nongnu.org On 10/05/2011 08:50 PM, Luiz Capitulino wrote: >>>> > > > 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. > > s/We can/ We can't I think we should divide stop causes into three groups: 1) those that are undone by QEMU itself: RSTATE_DEBUG RSTATE_SAVEVM RSTATE_PRE_MIGRATE RSTATE_RESTORE For these a lock/release scheme is definitely better. The VM should not start until none of these conditions is in effect, even after a "cont" command. 2) those that are undone by management: RSTATE_IO_ERROR For this we can add a new "retry" monitor command that guarantees no races if the user issues a "stop" or "cont" command while management is processing it. Effectively, it is also a lock/release scheme but controlled by management. 3) those that are undone by "cont": RSTATE_PRE_LAUNCH RSTATE_PAUSED RSTATE_WATCHDOG RSTATE_POST_MIGRATE RSTATE_PANICKED It put here the three runstates where the VM should really not be restarted at all. We can then add a new "start" command that only flips these five to RSTATE_RUNNING. So the runstate is composed of six elements: five lock/unlock states (of which only one can be unlocked by the user), and one running/paused state (composed of five pause reasons + "none"). That is, the runstate is a tuple like [debug, savevm, pre_migrate, restore, io_error, pause_reason] and for the VM to run it must look like [false, false, false, false, false, none]. The four monitor commands would be: 1) "stop": if runstate[pause_reason] == none then runstate[pause_reason] = paused 2) "retry": runstate[io_error] = false 3) "start": runstate[pause_reason] = none There could also be a differentiation between "start" and "start -f", where "-f" would be needed to get out of RSTATE_POST_MIGRATE, RSTATE_PANICKED and probably RSTATE_WATCHDOG too. 4) "cont": backwards compatibility provided by "retry"+"start -f". How does this look? Paolo