From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: qemu-kvm vs. qemu: Terminate cpu loop on reset? Date: Fri, 07 Jan 2011 16:57:31 +0100 Message-ID: <4D2737EB.6070002@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12C9F19F22B4529E4C287FDA" Cc: qemu-devel To: kvm Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:57334 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752392Ab1AGP6N (ORCPT ); Fri, 7 Jan 2011 10:58:13 -0500 Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12C9F19F22B4529E4C287FDA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, does anyone immediately know if this hunk from vl.c @@ -1278,6 +1197,10 @@ void qemu_system_reset_request(void) } else { reset_requested =3D 1; } + if (cpu_single_env) { + cpu_single_env->stopped =3D 1; + cpu_exit(cpu_single_env); + } qemu_notify_event(); } is (semantically) relevant for upstream as well? IIUC, it ensures that the kvm cpu loop is not continued if an IO access called into qemu_system_reset_request. If yes, then it would be a good time to push a patch: these bits will fall to dust on next merge from upstream (vl.c no longer has access to the cpu state). Jan --------------enig12C9F19F22B4529E4C287FDA 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nN+sACgkQitSsb3rl5xQV2QCg6sh6xvohGf92+T1hQs/bZJSY rSgAoJ6tM3BAjB+GXiP7TGgefdzP+NMl =QuAP -----END PGP SIGNATURE----- --------------enig12C9F19F22B4529E4C287FDA--