Re: [Qemu-devel] [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>

[Paolo Bonzini <pbonzini@redhat.com>]

Il 23/05/2014 15:35, Markus Armbruster ha scritto:
> Luiz Capitulino <lcapitulino@redhat.com> writes:
>
>> 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.
>
> 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