From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIGu6-00061h-TG for qemu-devel@nongnu.org; Mon, 02 Feb 2015 08:19:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIGu2-0003KB-So for qemu-devel@nongnu.org; Mon, 02 Feb 2015 08:19:02 -0500 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:46149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIGu2-0003K7-Lt for qemu-devel@nongnu.org; Mon, 02 Feb 2015 08:18:58 -0500 Received: by mail-wi0-f171.google.com with SMTP id l15so16648800wiw.4 for ; Mon, 02 Feb 2015 05:18:58 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54CF793D.6070404@redhat.com> Date: Mon, 02 Feb 2015 14:18:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20150122085127.5276.53895.stgit@PASHA-ISP.def.inno> <20150122085215.5276.8878.stgit@PASHA-ISP.def.inno> <54C9FE31.4090404@redhat.com> <001801d03ee3$c8cb7660$5a626320$@Dovgaluk@ispras.ru> <54CF6FA9.7090600@redhat.com> <28583.7738695138$1422880978@news.gmane.org> In-Reply-To: <28583.7738695138$1422880978@news.gmane.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v8 08/21] cpu: replay instructions sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgaluk , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, maria.klimushenkova@ispras.ru, alex.bennee@linaro.org, afaerber@suse.de, fred.konrad@greensocs.com On 02/02/2015 13:42, Pavel Dovgaluk wrote: >> From: Paolo Bonzini [mailto:pbonzini@redhat.com] >> On 02/02/2015 13:28, Pavel Dovgaluk wrote: >>>>>>> cpu->exception_index = EXCP_INTERRUPT; >>>>>>> next_tb = 0; >>>>>>> + qemu_notify_event(); >>>>> >>>>> Why is this needed? >>> It is needed to wake up iothread in replay mode. >>> Otherwise it waits for additional time and replay becomes too slow. >> >> What event (something from a timerlist?) is ready, that has not been >> notified to the iothread yet? qemu_notify_event() should never be >> needed in common case. It's probably missing somewhere else. > > I think in this case there are no events at all - just reading timers values > that were made while recording. > We have to replay these reads by waking iothread. I think the right place for this is in replay_read_next_clock then. Paolo