From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwulZ-0001Z4-Mm for qemu-devel@nongnu.org; Wed, 10 Jul 2013 09:49:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwulY-0004HT-DT for qemu-devel@nongnu.org; Wed, 10 Jul 2013 09:49:09 -0400 Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]:33634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwui9-0003N9-Qs for qemu-devel@nongnu.org; Wed, 10 Jul 2013 09:45:38 -0400 Received: by mail-ee0-f42.google.com with SMTP id c4so4957969eek.1 for ; Wed, 10 Jul 2013 06:45:36 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51DD6574.5030901@redhat.com> Date: Wed, 10 Jul 2013 15:45:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <51DAF7A5.3050904@greensocs.com> In-Reply-To: <51DAF7A5.3050904@greensocs.com> Content-Type: text/plain; charset=ISO-8859-1 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: Frederic Konrad , qemu-devel , "Edgar E. Iglesias" , Mark Burton 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?