From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34481)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Wnook-0001Ux-LR
	for qemu-devel@nongnu.org; Fri, 23 May 2014 08:43:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Wnooc-00041Q-BL
	for qemu-devel@nongnu.org; Fri, 23 May 2014 08:43:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:26486)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1Wnooc-00041J-2n
	for qemu-devel@nongnu.org; Fri, 23 May 2014 08:43:14 -0400
Date: Fri, 23 May 2014 08:43:11 -0400
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20140523084311.495cb040@redhat.com>
In-Reply-To: <20140523035038.GA23327@amt.cnet>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event
 for <clock offset='variable' basis='utc'/>
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: libvir-list@redhat.com, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Laine Stump <laine@laine.org>

On Fri, 23 May 2014 00:50:38 -0300
Marcelo Tosatti <mtosatti@redhat.com> 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.