From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uzpmk-0005NT-OF for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:06:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uzpmf-0005eS-TE for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:06:26 -0400 Received: from [2001:41d0:8:2b42::1] (port=45738 helo=ns232118.ovh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uzpmf-0005eL-NP for qemu-devel@nongnu.org; Thu, 18 Jul 2013 11:06:21 -0400 Message-ID: <51E80467.5020203@greensocs.com> Date: Thu, 18 Jul 2013 17:06:15 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <51DAF7A5.3050904@greensocs.com> <51DD6574.5030901@redhat.com> In-Reply-To: <51DD6574.5030901@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Undeterministic behaviour with icount. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Edgar E. Iglesias" , Mark Burton , qemu-devel On 10/07/2013 15:45, Paolo Bonzini wrote: > Il 08/07/2013 19:32, Frederic Konrad ha scritto: >> Hi everybody, >> >> We get some issues with reverse execution caused by indeterminism. >> >> Something catched our attention: >> static void icount_warp_rt(void *opaque), cpus.c:276 >> >> We have the feeling that icount is synchronized with rt_clock, is that >> possible? > When the CPU is idle, yes. > > Note that the same thing happened before the series you linked. This is > the relevant code: > > - /* Wait for either IO to occur or the next > - timer event. */ > - add = qemu_next_deadline(); > - /* We advance the timer before checking for IO. > - Limit the amount we advance so that early IO > - activity won't get the guest too far ahead. */ > - if (add > 10000000) > - add = 10000000; > - delta += add; > - qemu_icount += qemu_icount_round (add); > > It was adding to the icount while waiting for the next timer event to > happen. > >> According to this Paolo's series >> >> this must be called when the cpus are sleeping, but >> I saw this called frequently during the execution, is that the expected >> behaviour? > What workload are you running? For anything that is not CPU bound I'd > expect that to be the case. > > Paolo > >> If not what's the best way to fix that? Hi Paolo, Thanks for your answer. For the moment the workload is a kernel boot. We removed everything from the board. So if it's the case, vm_clock will run non deterministic and we can't replay. I just send a series about that. Fred