From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnpxe-0006Z8-Cs for qemu-devel@nongnu.org; Fri, 23 May 2014 09:56:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wnpxa-000610-9x for qemu-devel@nongnu.org; Fri, 23 May 2014 09:56:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnpxa-00060l-22 for qemu-devel@nongnu.org; Fri, 23 May 2014 09:56:34 -0400 Date: Fri, 23 May 2014 14:56:27 +0100 From: "Daniel P. Berrange" Message-ID: <20140523135627.GE31879@redhat.com> 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> <20140523134818.GB1358@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140523134818.GB1358@amt.cnet> Subject: Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: libvir-list@redhat.com, "qemu-devel@nongnu.org" , Luiz Capitulino , Markus Armbruster , Laine Stump On Fri, May 23, 2014 at 10:48:18AM -0300, Marcelo Tosatti wrote: > On Fri, May 23, 2014 at 03:35:19PM +0200, Markus Armbruster wrote: > > 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. > > I see. > > This also seems pretty harmful wrt losing events: > > /* Global, one-time initializer to configure the rate limiting > * and initialize state */ > static void monitor_protocol_event_init(void) > { > /* Limit RTC & BALLOON events to 1 per second */ > monitor_protocol_event_throttle(QEVENT_RTC_CHANGE, 1000); > > Better remove it. That is intentionally designed such that it doesn't cause any real problems actually - the monitor rate limiting code will only drop intermediate events - it is guaranteed you'll get the most recent event after the rate limiting period elapse. eg if the guest OS emits 6 events in the space on 1 second: RTC_CHANGE 353 RTC_CHANGE 1338 RTC_CHANGE 3542 RTC_CHANGE 255 RTC_CHANGE 522 RTC_CHANGE 320 then, the monitor rate limiting may discard all except the very last event. ie libvirt will see RTC_CHANGE == 320. The fact that it didn't see the previous events is no problem, because they're obsoleted by the new event. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|