From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38893 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbFwB-0006lx-Ss for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:17:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbFvt-0000uH-12 for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:17:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbFvs-0000tv-Q9 for qemu-devel@nongnu.org; Fri, 07 Jan 2011 12:16:56 -0500 Date: Fri, 7 Jan 2011 19:16:53 +0200 From: Gleb Natapov Message-ID: <20110107171653.GB10205@redhat.com> References: <4D2737EB.6070002@web.de> <20110107165359.GA10205@redhat.com> <4D274676.6000803@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D274676.6000803@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: Jan Kiszka Cc: qemu-devel , kvm 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 = 1; > >> } > >> + if (cpu_single_env) { > >> + cpu_single_env->stopped = 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. > > > > >> 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. It doesn't matter where the code resides as long as it is called on reset. > 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. -- Gleb.