From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBUf1-0001Dq-VM for qemu-devel@nongnu.org; Wed, 05 Oct 2011 12:49:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBUf0-0000oN-OR for qemu-devel@nongnu.org; Wed, 05 Oct 2011 12:49:35 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:34296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBUf0-0000ny-Cj for qemu-devel@nongnu.org; Wed, 05 Oct 2011 12:49:34 -0400 Message-ID: <4E8C8A9C.7090506@web.de> Date: Wed, 05 Oct 2011 18:49:32 +0200 From: Jan Kiszka 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> In-Reply-To: <4E8C87DF.5080201@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8EA954DB048BDD45B258A469" Sender: jan.kiszka@web.de 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 , qemu-devel@nongnu.org, Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EA954DB048BDD45B258A469 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-05 18:37, 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 th= e >> > 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 progres= s >> > (due to a user pressing the stop button, or migration, or cpu hotpl= ug, >> > or whatever). For the human monitor, it's not so intuitive, but th= e >> > situation is so rare we can just rely on the user to issue cont aga= in. >> >> Making this kind of user-visible change would be a bad idea. >=20 > The current situation is a bad idea. >=20 > Consider a user-initiated or qemu-initiated stop; the user starts to > deal with it, types 'cont', and as the Enter key is being depressed > another qemu-initiated stop comes along. The 'cont' restarts the guest= > even though the second event was not dealt with. You always have this kind of problems when you attach two keyboards to the same console. A counting stop/cont will just create different effects of the same problem but not solve it. >=20 >> We are talking about multiple stop states here, but only a single >> function (vm_stop) to enter them - maybe that's not optimal. But the >> point is that we were missing one stop-to-stop transition. And that >> needs to be fixed, either inside vm_stop or when it is called. >=20 > Those stops are orthogonal. There is no relationship between a > migration stop, a user stop, an ENOSPC stop, a hotplug stop, and a > debugger stop. There is no reason to start inventing stop-to-stop > transitions between them. A 'cont' intended for one should not undo > another. No, they aren't. They are all different states, and we need to model transitions between them. If there are redundant states, lets collapse th= em. >=20 > There are two ways to do this, one is to store a set of stop reasons an= d > let both 'stop' and 'cont' specify the reason, the other, which is > simpler but less safe, is to use a reference counting approach. >=20 >> >> If you want to lock the VM into paused state, add a new symmetric API >> that does precisely this. That API would send the VM into RSTATE_LOCKE= D >> if it is not yet stopped on lock or is still locked on resume. That >> would avoid redefining stop states that have no use for lock-counting >> semantics. >> >=20 > Which stop states would these be? When would you want one cont to undo= > two stops? No, cont would remain cont: the resume-after-stop command. Locking would never be user-exposed. It would be a QEMU-internal thing, used when there must be no resume for a certain finite while (e.g. during migration or savevm). I think one problem with the current state machine is that it does not differentiate between these two types of "sto= p". Jan --------------enig8EA954DB048BDD45B258A469 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.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MipwACgkQitSsb3rl5xRMqQCgqPiQ8Ihc1NV4ijKH/BUzSXQT Md4AoM7IVufW6Uomj3nihsw53PQuJDUt =vzPm -----END PGP SIGNATURE----- --------------enig8EA954DB048BDD45B258A469--