From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjkSJ-0003Ss-0l for qemu-devel@nongnu.org; Wed, 07 Oct 2015 04:52:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjkSF-0006MA-0F for qemu-devel@nongnu.org; Wed, 07 Oct 2015 04:52:10 -0400 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:33138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjkSE-0006Lu-Qt for qemu-devel@nongnu.org; Wed, 07 Oct 2015 04:52:06 -0400 Received: by wiclk2 with SMTP id lk2so202706477wic.0 for ; Wed, 07 Oct 2015 01:52:06 -0700 (PDT) Sender: Paolo Bonzini References: <1444161658-15038-1-git-send-email-pbonzini@redhat.com> <1444161658-15038-5-git-send-email-pbonzini@redhat.com> <35633.6639299572$1444206177@news.gmane.org> From: Paolo Bonzini Message-ID: <5614DD31.4080000@redhat.com> Date: Wed, 7 Oct 2015 10:52:01 +0200 MIME-Version: 1.0 In-Reply-To: <35633.6639299572$1444206177@news.gmane.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] events doubts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pavel Dovgaluk , qemu-devel@nongnu.org On 07/10/2015 10:21, Pavel Dovgaluk wrote: > There are two kinds of events: > - read from the log and injected immediately (user input, network input) > - read from the log and wait for corresponding event in the queue (BH) > > We cannot inject BH event immediately because we do not have any information > about callback Actually we do (indirectly, through aio_bh_call). But that may not be the central issue, because... > and to preserve consistency - BH cannot be processed before > it is scheduled by qemu core. ... you are processing them differently anyway between record mode (where the BH is scheduled by the core) and replay (where the BH is called directly). In fact, I don't understand what introduces the difference between record and replay that requires special handling of ptimers' bottom halves. In both cases, the ptimer triggers at the desired time (based on checkpoints) and then the bottom half is called as soon as possible. Why is a separate async event necessary? Because we only care about bottom halves from ptimers, their order should be the same for both record and replay. If bottom halves async events could be removed, that would simplify a lot the code, and it would make it a lot easier to understand for me. Paolo