From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrucb-0000nz-J7 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:02:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrucX-0004rs-8b for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:02:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrucW-0004rK-W3 for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:02:21 -0500 Message-ID: <4F26CD15.3020206@redhat.com> Date: Mon, 30 Jan 2012 18:02:13 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1327061206-9404-1-git-send-email-pbonzini@redhat.com> <1327061206-9404-5-git-send-email-pbonzini@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] pl031: switch clock base to rtc_clock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On 01/30/2012 05:54 PM, Peter Maydell wrote: >> > This lets the user specify the desired semantics. By default, the RTC >> > will follow adjustments from the host's NTP client, and will remain in >> > sync when the virtual machine is stopped. The previous behavior, which >> > provides determinism with both icount and qtest, remains available with >> > "-rtc clock=vm". >> > >> > pl031 supports migration, so we need to convert the time >> > base from rtc_clock to vm_clock and back for backwards compatibility. > If it would be cleaner I'm entirely happy for us to do a version > bump and break binary compatibility. (We bump the version on > the CPUState pretty regularly anyhow; save/load for ARM devices > currently is mostly for the benefit of snapshot save/restore rather > than between-qemu-versions migration.) Actually it's not really just backwards compatibility. rtc_clock may be counting up from a different time base on the source and destination machine. vm_clock is the only time base that is migrated, so it is the only one that is safe to use in the data stream. Perhaps I could transfer the timer deadline relative to the current rtc_clock value and convert it again on the destination. However, it would be basically the same code that transfers the value relative to the vm_clock; it's just a different offset to apply. Paolo