From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47012 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbG9V-0007tL-8u for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:31:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbG9T-0004wo-Ml for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:31:01 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:42455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbG9T-0004wM-91 for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:30:59 -0500 Message-ID: <4D274DD1.1020702@web.de> Date: Fri, 07 Jan 2011 18:30:57 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4D2737EB.6070002@web.de> <20110107165359.GA10205@redhat.com> <4D274676.6000803@web.de> <20110107171653.GB10205@redhat.com> In-Reply-To: <20110107171653.GB10205@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AEF191B8EA95734710249BD" 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) --------------enig9AEF191B8EA95734710249BD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 07.01.2011 18:16, Gleb Natapov wrote: > On Fri, Jan 07, 2011 at 05:59:34PM +0100, Jan Kiszka wrote: >> 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 th= at >>>> 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 di= g >> into the details. >> >>> >>>> If yes, then it would be a good time to push a patch: these bits wil= l >>>> 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 i= t >> upstream.=20 > It doesn't matter where the code resides as long as it is called on > reset. It technically matters for the build process (vl.c is built once these days, cpus.c is built per target). In any case, we apparently need to fix upstream, I'm playing with some approach. >=20 >> If upstream does not need it, we have to understand why and= >> maybe adopt its pattern (the ultimate goal is unification anyway). >> > I don't consider kvm upstream as working product. The goal should be > moving to qemu-kvm code in upstream preserving all the knowledge we > acquired while making it production grade code. We had this discussion before. My goal remains to filter the remaining upstream fixes out of the noise, adjust both versions so that they are apparently identical, and then switch to a single version. We are on a good track now. I predict that we will be left with only one or two major additional features in qemu-kvm in a few months from now, no more duplications with subtle differences, and production-grade kvm upstream stability. Jan --------------enig9AEF191B8EA95734710249BD 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/ iEYEARECAAYFAk0nTdEACgkQitSsb3rl5xRpvACaAqBixL7T2K3/ybUTXcEf+u3T m3cAoJHA7ghwUZWq4b3l4+uR8b2iN+J8 =pU7Z -----END PGP SIGNATURE----- --------------enig9AEF191B8EA95734710249BD--