Re: [libvirt] [Qemu-devel] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>
Il 23/05/2014 15:35, Markus Armbruster ha scritto:
Luiz Capitulino <lcapitulino(a)redhat.com> writes:
> On Fri, 23 May 2014 00:50:38 -0300
> Marcelo Tosatti <mtosatti(a)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