qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for


From: Marcelo Tosatti
Subject: Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>
Date: Fri, 23 May 2014 10:48:18 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 23, 2014 at 03:35:19PM +0200, Markus Armbruster wrote:
> Luiz Capitulino <address@hidden> writes:
> 
> > On Fri, 23 May 2014 00:50:38 -0300
> > Marcelo Tosatti <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]