From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnx9N-0000aX-HK for qemu-devel@nongnu.org; Fri, 23 May 2014 17:37:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wnx9C-0003G1-Ms for qemu-devel@nongnu.org; Fri, 23 May 2014 17:37:13 -0400 Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:44541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnx9C-0003Fu-Fn for qemu-devel@nongnu.org; Fri, 23 May 2014 17:37:02 -0400 Received: by mail-wi0-f178.google.com with SMTP id cc10so1508643wib.17 for ; Fri, 23 May 2014 14:37:01 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <537FBF78.7000808@redhat.com> Date: Fri, 23 May 2014 23:36:56 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1400756850-19807-1-git-send-email-laine@laine.org> <1400756850-19807-4-git-send-email-laine@laine.org> <537E50FA.1000304@redhat.com> <20140523035038.GA23327@amt.cnet> <20140523084311.495cb040@redhat.com> <87fvk0mxd4.fsf@blackfin.pond.sub.org> In-Reply-To: <87fvk0mxd4.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Luiz Capitulino Cc: libvir-list@redhat.com, Marcelo Tosatti , "qemu-devel@nongnu.org" , Laine Stump Il 23/05/2014 15:35, Markus Armbruster ha scritto: > Luiz Capitulino writes: > >> On Fri, 23 May 2014 00:50:38 -0300 >> Marcelo Tosatti wrote: >> >>>> Then the guest triggers an RTC update, so qemu sends an event, but the >>>> event is lost. Then libvirtd starts again, and doesn't realize the >>>> event is lost. >>> >>> Yes, but that case is also true for any other QMP asynchronous event, >>> and therefore should be handled generically i suppose (QMP channel data >>> should be maintained across libvirtd shutdown). Luiz? >> >> Maintaining QMP channel data doesn't solve this problem, because all sorts >> of race conditions are still possible. For example, libvirt could crash >> after having received the event but before handling it. >> >> The most reliable way we found to solve this problem, and that's what we >> do for other events, is to allow libvirt to query the information the event >> is reporting. An event is nothing more than a state change in QEMU, and QEMU >> state is persistent during the life time of the VM, so we allow libvirt to >> query the state of anything that may send an event. > > In fact, this is a general rule: when libvirt tracks an event, it also > needs a way to poll for the information in the event. > It can be polled even right now. It's not pretty, but it's doable. You can get the current time via the qom-get command, and then follow the same algorithm as QEMU: time_t seconds; if (rtc_date_offset == -1) { if (rtc_utc) { seconds = mktimegm(tm); } else { struct tm tmp = *tm; tmp.tm_isdst = -1; /* use timezone to figure it out */ seconds = mktime(&tmp); } } else { seconds = mktimegm(tm) + rtc_date_offset; } return seconds - time(NULL); Unfortunately the QOM path to the RTC device is not stable. We can add a /machine/rtc link, and if the PPC guys implement the link and current-time property as well, the same mechanism can work for any board. Paolo