From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP8re-0003yE-Rh for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TP8ra-0001PS-PU for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:27:34 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:58208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP8ra-0001PC-Ge for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:27:30 -0400 Date: Fri, 19 Oct 2012 05:27:29 -0400 (EDT) From: Paolo Bonzini Message-ID: <1020421226.13368559.1350638849130.JavaMail.root@redhat.com> In-Reply-To: <20121018134256.5f6d745d@doriath.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qmp: handle stop/cont in INMIGRATE state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org > What happens is that a stop command while in INMIGRATE state will just > be ignored. Actually, any stops while in a state that pauses vCPUs > are ignored. > > Also, I don't understand what you meant by "racy", care to elaborate? Case 1: Case 2: user runs qemu -incoming -S user runs qemu -incoming -S source connects cont command received cont command received source connects In case 1, the VM is resumed at the end of migration, in case 2 it is not and an error is reported on QMP. After this patch, it is always resumed. Case 1: Case 2: user runs qemu -incoming user runs qemu -incoming source connects stop command received stop command received source connects In case 1, the VM runs for a blink of an eye and then stops. In case 2 it just starts, with no error reported. > > In addition, there's nothing that really prevents the user from > > typing the block device's passwords before incoming migration is > > done, so we may as well allow that. > > Have you tried it? We seem to support that already. With HMP yes, with QMP no. You just get "An incoming migration is expected before this command can be executed" and no clue that disks are encrypted. Paolo