]> xenbits.xensource.com Git - people/liuw/libxenctrl-split/libvirt.git/commit
qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>
authorLaine Stump <laine@laine.org>
Wed, 21 May 2014 09:54:34 +0000 (12:54 +0300)
committerLaine Stump <laine@laine.org>
Mon, 26 May 2014 10:58:09 +0000 (13:58 +0300)
commitb62d67da3e106d8081877499f143996fd50e2918
tree7d1a3d23990afc168aa4837d867a601dbe9611c4
parentb8efa6f2e301bf8918429818c88654a1ee4643a1
qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>

commit e31b5cf393857 attempted to fix libvirt's
VIR_DOMAIN_EVENT_ID_RTC_CHANGE, which is documentated to always
provide the new offset of the domain's real time clock from UTC. The
problem was that, in the case that qemu is provided with an "-rtc
base=x" where x is an absolute time (rather than "utc" or
"localtime"), the offset sent by qemu's RTC_CHANGE event is *not* the
new offset from UTC, but rather is the sum of all changes to the
domain's RTC since it was started with base=x.

So, despite what was said in commit e31b5cf393857, if we assume that
the original value stored in "adjustment" was the offset from UTC at
the time the domain was started, we can always determine the current
offset from UTC by simply adding the most recent (i.e. current) offset
from qemu to that original adjustment.

This patch accomplishes that by storing the initial adjustment in the
domain's status as "adjustment0". Each time a new RTC_CHANGE event is
received from qemu, we simply add adjustment0 to the value sent by
qemu, store that as the new adjustment, and forward that value on to
any event handler.

This patch (*not* e31b5cf393857, which should be reverted prior to
applying this patch) fixes:

https://bugzilla.redhat.com/show_bug.cgi?id=964177

(for the case where basis='utc'. It does not fix basis='localtime')
src/conf/domain_conf.c
src/conf/domain_conf.h
src/qemu/qemu_command.c
src/qemu/qemu_process.c