From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBVoU-0005YF-9j for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:03:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBVoS-0007Wc-Tp for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:03:26 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:47922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBVoS-0007WT-FR for qemu-devel@nongnu.org; Wed, 05 Oct 2011 14:03:24 -0400 Message-ID: <4E8C9BBB.7040804@web.de> Date: Wed, 05 Oct 2011 20:02:35 +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> <4E8C8A9C.7090506@web.de> <4E8C9018.5000908@redhat.com> In-Reply-To: <4E8C9018.5000908@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB050626D736CEA16A3C14EC8" 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) --------------enigB050626D736CEA16A3C14EC8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-05 19:12, Avi Kivity wrote: > On 10/05/2011 06:49 PM, Jan Kiszka wrote: >> 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.=20 >> 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 w= ork >> >> 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. >> > >> > Consider a user-initiated or qemu-initiated stop; the user starts t= o >> > 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 > Let's examine a concrete example: a user is debugging a guest, which > stops at a breakpoint. Meanwhile a live migration is going on, > involving internal stops. When the guest does manage to run for a bit,= > it runs out of disk space, generating a stop, which the management agen= t > resolves by allocating more space and issuing a cont. >=20 > With a counting cont, no matter in what order these events happen, > things work out fine. How do they work out with your proposal? We can enforce stop for temporal reasons (migration/savevm), something that overrules user/management initiated stops. BTW, does stop due to migration actually have a window where it accepts other commands? I thought that phase is synchronous. Then we would just have to implement proper state saving/restoring. Anyway, there is no point in lock counting for stop reasons that require external synchronization anyway. gdb vs. management stack vs. human monitor - nothing is solved by counting the stops, they all can step on each other's shoes. Even worse, exposing a counting stop via the user interface requires additional interfaces to recover lost or forgotten locks. We've discussed this in the past IIRC. Jan --------------enigB050626D736CEA16A3C14EC8 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/ iEYEARECAAYFAk6Mm74ACgkQitSsb3rl5xS6FgCghsWT3cSgoHmFoVDRNjd4vsyX 5ksAn0pMrQvoyDhE1reVEvMYt88yi8zr =R5JI -----END PGP SIGNATURE----- --------------enigB050626D736CEA16A3C14EC8--