From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 3/3] stop the periodic RTC update timer Date: Mon, 09 Jan 2012 09:19:02 +0100 Message-ID: <4F0AA2F6.20005@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , "avi@redhat.com" , "aliguori@us.ibm.com" , "Zhang, Xiantao" , "Shan, Haitao" , "kvm@vger.kernel.org" To: "Zhang, Yang Z" Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:56730 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521Ab2AIITK (ORCPT ); Mon, 9 Jan 2012 03:19:10 -0500 Received: by iaeh11 with SMTP id h11so6372643iae.19 for ; Mon, 09 Jan 2012 00:19:10 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 01/06/2012 08:37 AM, Zhang, Yang Z wrote: > VMSTATE_BUFFER(cmos_data, RTCState), > VMSTATE_UINT8(cmos_index, RTCState), > - VMSTATE_INT32(current_tm.tm_sec, RTCState), > - VMSTATE_INT32(current_tm.tm_min, RTCState), > - VMSTATE_INT32(current_tm.tm_hour, RTCState), > - VMSTATE_INT32(current_tm.tm_wday, RTCState), > - VMSTATE_INT32(current_tm.tm_mday, RTCState), > - VMSTATE_INT32(current_tm.tm_mon, RTCState), > - VMSTATE_INT32(current_tm.tm_year, RTCState), > + VMSTATE_INT64(offset, RTCState), > VMSTATE_TIMER(periodic_timer, RTCState), > VMSTATE_INT64(next_periodic_time, RTCState), > - VMSTATE_INT64(next_second_time, RTCState), > - VMSTATE_TIMER(second_timer, RTCState), > - VMSTATE_TIMER(second_timer2, RTCState), > + VMSTATE_TIMER(update_timer, RTCState), > + VMSTATE_INT64(next_update_time, RTCState), > + VMSTATE_TIMER(alarm_timer, RTCState), > + VMSTATE_INT64(next_alarm_time, RTCState), Hi Yang, this looks like a very nice piece of work, but this unfortunately breaks migration. Also, I'm not sure if the update in progress flag still works. Clients are supposed to wait for UIP=0 before reading the RTC, and an update is supposed to be at least 220 microseconds away when UIP=0. Also, it would be nice if you could based these patches on the 4-patch series I sent recently that fixes some bugs with interrupts and 12-hour emulation. There is another aspect of RTC emulation that is missing in the current code; after setting the clock, the next second tick will occur in exactly 500 ms. I have patches to fix this, but it looks like it could be incorporated in your series, too. Paolo