From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9bpQ-0006Vk-3v for qemu-devel@nongnu.org; Tue, 22 Jul 2014 11:18:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9bpL-00017o-PQ for qemu-devel@nongnu.org; Tue, 22 Jul 2014 11:18:08 -0400 Received: from zimbra3.corp.accelance.fr ([2001:4080:204::2:8]:57652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9bpL-00017U-Gl for qemu-devel@nongnu.org; Tue, 22 Jul 2014 11:18:03 -0400 Date: Tue, 22 Jul 2014 17:17:57 +0200 (CEST) From: Sebastian Tanase Message-ID: <1738104785.20049265.1406042277758.JavaMail.root@openwide.fr> In-Reply-To: <53CE7C46.7010908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Paolo Bonzini 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 ----- Mail original ----- > De: "Paolo Bonzini" > =C3=80: "Sebastian Tanase" > Cc: aliguori@amazon.com, afaerber@suse.de, rth@twiddle.net, "peter maydel= l" , > michael@walle.cc, alex@alex.org.uk, stefanha@redhat.com, lcapitulino@redh= at.com, crobinso@redhat.com, > armbru@redhat.com, wenchaoqemu@gmail.com, quintela@redhat.com, kwolf@redh= at.com, mst@redhat.com, "camille begue" > , qemu-devel@nongnu.org > Envoy=C3=A9: Mardi 22 Juillet 2014 16:59:18 > Objet: Re: [RFC PATCH V4 0/6] icount: Implement delay algorithm between g= uest and host clocks >=20 > 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). >=20 > 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. Just to be sure I don't missunderstand, when you say "without icount" you refer to qemu_icount_bias (aka when the vcpu is inactive), right? Sebastian >=20 > > Supposing the patch that changes vm_clock_warp_start from 0 to -1 > > is accepted, >=20 > ... which shouldn't be a problem,... :) >=20 > > 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: > >=20 > > int64_t cpu_get_clock_offset(void) > > { > > int64_t ti; > > unsigned start; > >=20 > > do { > > start =3D > > seqlock_read_begin(&timers_state.vm_clock_seqlock); > > ti =3D -timers_state.cpu_clock_offset; > > } while (seqlock_read_retry(&timers_state.vm_clock_seqlock, > > start)); > >=20 > > return ti; > > } > >=20 > > that will return the cpu_clock_offset field. >=20 > Indeed what I was proposing is a bit more sloppy. If you do that, > you > have to make the function a bit more general: >=20 > ti =3D timers_state.cpu_clock_offset; > if (!timers_state.cpu_ticks_enabled) { > ti -=3D get_clock(); > } > ... >=20 > return -ti; >=20 > 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(). >=20 > Paolo >=20