From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIHpv-0002RY-IX for qemu-devel@nongnu.org; Mon, 02 Feb 2015 09:18:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIHps-00058f-CS for qemu-devel@nongnu.org; Mon, 02 Feb 2015 09:18:47 -0500 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:47166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIHps-00058V-2d for qemu-devel@nongnu.org; Mon, 02 Feb 2015 09:18:44 -0500 Received: by mail-wi0-f170.google.com with SMTP id bs8so15990140wib.1 for ; Mon, 02 Feb 2015 06:18:43 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54CF873F.4060101@redhat.com> Date: Mon, 02 Feb 2015 15:18:39 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20150122085127.5276.53895.stgit@PASHA-ISP.def.inno> <20150122085221.5276.24836.stgit@PASHA-ISP.def.inno> <54CA00FE.3000605@redhat.com> <23862.806443549$1422885088@news.gmane.org> In-Reply-To: <23862.806443549$1422885088@news.gmane.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v8 09/21] replay: interrupts and exceptions 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 14:50, Pavel Dovgaluk wrote: > I think not. We just have to write number of already executed instructions. > This number is not linked to exception event. They could be read in replay while > processing some other event. > I was referring to replay_put_event(EVENT_EXCEPTION) only. In principle you could run EVENT_EXCEPTION concurrently with other event writes, for example: + replay_mutex_lock(); + replay_put_event(EVENT_CLOCK + kind); + replay_put_qword(clock); + replay_mutex_unlock(); and get EVENT_CLOCK + kind (1 byte) EVENT_EXCEPTION (1 byte) clock (8 bytes) in the replay stream. I know it's really unlikely, perhaps even impossible in the current QEMU architecture that is dominated by the big QEMU lock. But the right thing to do is to lock the mutex around all event writes. Even if the write itself is atomic, it could happen in the middle of another write if you do not lock the mutex. Paolo