From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBpa1-000652-CH for qemu-devel@nongnu.org; Thu, 06 Oct 2011 11:09:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBpa0-0007vE-0u for qemu-devel@nongnu.org; Thu, 06 Oct 2011 11:09:49 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:55438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBpZz-0007uf-LE for qemu-devel@nongnu.org; Thu, 06 Oct 2011 11:09:47 -0400 Message-ID: <4E8DC463.4090203@web.de> Date: Thu, 06 Oct 2011 17:08:19 +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> <4E8C9BBB.7040804@web.de> <4E8DBAD0.7070406@redhat.com> In-Reply-To: <4E8DBAD0.7070406@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B45CD08D9472F01C6CBF7AE" 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) --------------enig3B45CD08D9472F01C6CBF7AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-06 16:27, Avi Kivity wrote: > On 10/05/2011 08:02 PM, Jan Kiszka wrote: >> > >> > Let's examine a concrete example: a user is debugging a guest, whic= h >> > 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 >> agent >> > resolves by allocating more space and issuing a cont. >> > >> > 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. >=20 > Migration resume shouldn't overrule user stop. That's not what I had in mind. Migration stop could overrule user resume.= But that discussion is moot as there is no time span where this could happen. Migration just needs to re-enter the original state on error, savevm/loadvm restore what it found on entry. All this is atomic /wrt other agents. >=20 > It's really simple. If any agent wants the system stopped, it's > stopped. Only when no one wants it stopped, it may run. >=20 >> >> BTW, does stop due to migration actually have a window where it accept= s >> other commands? I thought that phase is synchronous. Then we would jus= t >> have to implement proper state saving/restoring. >=20 > Save: ++stop_count, restore: --stop_count. >=20 >> >> Anyway, there is no point in lock counting for stop reasons that requi= re >> external synchronization anyway. gdb vs. management stack vs. human >> monitor - nothing is solved by counting the stops, they all can step o= n >> each other's shoes. >=20 > Please elaborate. Every agent can issue every monitor command. If you have a gdb session running, you don't want the management stack to migrate your VM away or mess with it otherwise. If you try to migrate a machine, you don't want any other agent change its configuration beforehand, adding a device that is not present on the target, etc. >=20 >> 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. >> >=20 > Agree with that. So there's the second proposal: >=20 > vm_stop(unsigned reason) > { > if (!stop_state) { > do_vm_stop(); > } > stop_state |=3D 1 << reason; > } >=20 > vm_resume(unsigned reason) > { > stop_state &=3D ~(1 << reason); > if (!stop_state) { > do_vm_resume(); > } > } >=20 > so now each agent is separated from the other. >=20 Stop reasons are orthogonal to agents. BTW, the above model would still require extending the user interface to report pending stop reasons and allow specifying resume reasons. Jan --------------enig3B45CD08D9472F01C6CBF7AE 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/ iEYEARECAAYFAk6NxGgACgkQitSsb3rl5xRMDQCgomT4P8wEzdncx/qEtS11kZBM ndIAoITSn7ATauen0HVTm+OJrQg64fEu =o56O -----END PGP SIGNATURE----- --------------enig3B45CD08D9472F01C6CBF7AE--