From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9bXn-000359-4l for qemu-devel@nongnu.org; Tue, 22 Jul 2014 11:00:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9bXe-0003Bd-Ml for qemu-devel@nongnu.org; Tue, 22 Jul 2014 10:59:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9bXe-0003BA-ED for qemu-devel@nongnu.org; Tue, 22 Jul 2014 10:59:46 -0400 Message-ID: <53CE7C46.7010908@redhat.com> Date: Tue, 22 Jul 2014 16:59:18 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <47507527.20044186.1406037761337.JavaMail.root@openwide.fr> In-Reply-To: <47507527.20044186.1406037761337.JavaMail.root@openwide.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH V4 0/6] icount: Implement delay algorithm between guest and host clocks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Tanase Cc: kwolf@redhat.com, peter maydell , aliguori@amazon.com, wenchaoqemu@gmail.com, quintela@redhat.com, qemu-devel@nongnu.org, mst@redhat.com, stefanha@redhat.com, armbru@redhat.com, lcapitulino@redhat.com, michael@walle.cc, camille begue , alex@alex.org.uk, crobinso@redhat.com, afaerber@suse.de, rth@twiddle.net Il 22/07/2014 16:02, Sebastian Tanase ha scritto: > Yes, QEMU_CLOCK_VIRTUAL counts up from qemu_clock_get_ns(QEMU_CLOCK_REALTIME) > on ARM (I have only tested with the versatilepb and vexpress boards). That's a bug to fix indeed, then---it should count up from 0 without icount, and icount shouldn't affect this. Thanks for investigating it. > Supposing the patch that changes vm_clock_warp_start from 0 to -1 is accepted, ... which shouldn't be a problem,... :) > I could use the information in timers_state.cpu_clock_offset instead of recalculating > the offset. Besides, given that I only need this particular field from the whole > structure, I think I don't have to make timers_state public; I could add a function > in cpus.c, for example: > > int64_t cpu_get_clock_offset(void) > { > int64_t ti; > unsigned start; > > do { > start = seqlock_read_begin(&timers_state.vm_clock_seqlock); > ti = -timers_state.cpu_clock_offset; > } while (seqlock_read_retry(&timers_state.vm_clock_seqlock, start)); > > return ti; > } > > that will return the cpu_clock_offset field. Indeed what I was proposing is a bit more sloppy. If you do that, you have to make the function a bit more general: ti = timers_state.cpu_clock_offset; if (!timers_state.cpu_ticks_enabled) { ti -= get_clock(); } ... return -ti; even though in cpus.c you'll only be using it when cpu_ticks_enabled is true. See cpu_enable_ticks() and cpu_disable_ticks(). Paolo