From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlDJ-0007A2-Lk for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:05:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqlDG-0002Cz-1h for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:05:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqlDF-0002Cv-OR for qemu-devel@nongnu.org; Mon, 26 Oct 2015 13:05:37 -0400 References: <014501d10fec$8b2548b0$a16fda10$@samsung.com> From: Eric Blake Message-ID: <562E5D60.7060501@redhat.com> Date: Mon, 26 Oct 2015 11:05:36 -0600 MIME-Version: 1.0 In-Reply-To: <014501d10fec$8b2548b0$a16fda10$@samsung.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N4u1RnSvltCiL6DvfQPv5X5xs3PoOtBET" Subject: Re: [Qemu-devel] [PATCH] migration: Introduce MIGRATION_STATUS_FINISHING List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Fedin , qemu-devel@nongnu.org Cc: 'Amit Shah' , 'Luiz Capitulino' , 'Juan Quintela' This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N4u1RnSvltCiL6DvfQPv5X5xs3PoOtBET Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/26/2015 06:47 AM, Pavel Fedin wrote: > This status is set after vm_stop_force_state(), and is telling us that = all > CPUs are stopped, and we are finishing up with the migration. >=20 > Also, call notifier_list_notify() when this status is set. This will be= > necessary for ITS live migration on ARM, which will have to dump its st= ate > into guest RAM at this point. >=20 > Signed-off-by: Pavel Fedin > --- Interface review only: > +++ b/qapi-schema.json > @@ -430,6 +430,8 @@ > # > # @active: in the process of doing migration. > # > +# @finishing: migration is being finished, CPUs have been stopped. > +# Missing a '(since 2.5)' notation. Also, adding new user-visible states has a tendency to break existing clients that aren't prepared for unexpected states (although technically such bugs are in the client - in the past, libvirt used to be one such client, although we've tried to fix it to gracefully ignore unknown states). Are we sure no other existing state works for this? I'm not opposed to the addition, just wanting to make sure we have good reason for it. One design idea for adding new states is making sure the new state will not be exposed unless the client specifies some new option to enable the state, so that old clients will never see the state and new clients have expressed their interest in the state by opting-in to it with the new option. > # @completed: migration is finished. > # > # @failed: some error occurred during migration process. > @@ -439,7 +441,7 @@ > ## > { 'enum': 'MigrationStatus', > 'data': [ 'none', 'setup', 'cancelling', 'cancelled', > - 'active', 'completed', 'failed' ] } > + 'active', 'finishing', 'completed', 'failed' ] } > =20 > ## > # @MigrationInfo >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --N4u1RnSvltCiL6DvfQPv5X5xs3PoOtBET Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWLl1gAAoJEKeha0olJ0Nqts8H/AgTqx6ffI5kBROC0rZ2WzS6 SpyZqcugMtftvt6+glvBrJnTFaGGRfge8rvvWhiXdYvomKlmRsfLTcjW0QmsVviI 7mMY/Qf/TnHZozoPL+mAXvTwor8Yutbm8vkfVL//o2aV0CFvbx6EnMa/IItWs+A1 Sm6c8tW2gWU2zhndj49stPE0iSKh3lE2DyvPk3CLnYjoGNZgQk3Xa1X/Qjo/HHl3 mFwmvzD/HtOki6AZUuwbB5JqvrM1HDq2x1CwwdxPwf08Pkimm4U97KO93K715t2y hROK14FSP+Jo7JpBQsVIjz5Mvf3zl+RK7dO+D6vD3OMQ09vF/cNqDBOldlPSe6o= =6oj0 -----END PGP SIGNATURE----- --N4u1RnSvltCiL6DvfQPv5X5xs3PoOtBET--