From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46669 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbFf8-0005f9-R7 for qemu-devel@nongnu.org; Fri, 07 Jan 2011 11:59:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbFf7-0002AO-Ky for qemu-devel@nongnu.org; Fri, 07 Jan 2011 11:59:38 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:45961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbFf7-00029u-8a for qemu-devel@nongnu.org; Fri, 07 Jan 2011 11:59:37 -0500 Message-ID: <4D274676.6000803@web.de> Date: Fri, 07 Jan 2011 17:59:34 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4D2737EB.6070002@web.de> <20110107165359.GA10205@redhat.com> In-Reply-To: <20110107165359.GA10205@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig465DAF0D4C86AEA01054EF1B" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel , kvm This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig465DAF0D4C86AEA01054EF1B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 07.01.2011 17:53, Gleb Natapov wrote: > On Fri, Jan 07, 2011 at 04:57:31PM +0100, Jan Kiszka wrote: >> 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. >> > I don't know TCG enough to tell. If TCG can continue vcpu execution > after io without checking reset_requested then it is relevant for > upstream too. I was first of all thinking about kvm upstream, but their handling differ much less upstream than in current qemu-kvm. Anyway, need to dig into the details. >=20 >> 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). >> > On a next merge cpu state will have to be exposed to vl.c then. This > code cannot be dropped in qemu-kvm. I think a cleaner approach, even if it's only temporarily required, is to move that code to cpus.c. That's likely also the way when we need it upstream. If upstream does not need it, we have to understand why and maybe adopt its pattern (the ultimate goal is unification anyway). Jan --------------enig465DAF0D4C86AEA01054EF1B 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/ iEYEARECAAYFAk0nRnYACgkQitSsb3rl5xQ2uwCgv8auFg6mOeO8iqCspQU1Iqgc F0kAn3BmQ/+OjteT66VRftktbXSGWPyh =bI97 -----END PGP SIGNATURE----- --------------enig465DAF0D4C86AEA01054EF1B--