diff options
author | Junlian Bell <zhongjun@sangfor.com.cn> | 2016-09-26 20:41:01 +0800 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2016-10-04 10:00:25 +0200 |
commit | 3cf294eebc98da6e2ff7976fcdf6a9b41984840e (patch) | |
tree | 62acad2b2be2151d5c65c38ce93344902204891d /docs | |
parent | 1d5b128cbeeab638f772e88674f22e36b1b024e5 (diff) | |
download | qemu-3cf294eebc98da6e2ff7976fcdf6a9b41984840e.tar.gz qemu-3cf294eebc98da6e2ff7976fcdf6a9b41984840e.tar.bz2 qemu-3cf294eebc98da6e2ff7976fcdf6a9b41984840e.zip |
MC146818 RTC: coordinate guest clock base to destination host after migration
qemu tracks guest time based on vector [base_rtc, last_update], in which
last_update stands for a monotonic tick which is actually uptime of the
host.
according to rtc implementation codes of recent releases and upstream,
after
migration, the time base vector [base_rtc, last_update] isn't updated to
coordinate with the destionation host, ie. qemu doesnt update last_update
to
uptime of the destination host.
what problem have we got because of this bug? after migration, guest time
may
jump back to several days ago, that will make some critical business
applications,
such as lotus notes, malfunction.
this patch is trying to fix the problem. first, when vmsave in progress,
we
rtc_update_time to refresh time stamp in cmos array, then during
vmrestore,
we rtc_set_time to update qemu base_rtc and last_update variable according
to time
stamp in cmos array.
Signed-off-by: Junlian Bell <zhongjun@sangfor.com.cn>
Message-Id: <20160926124101.2364-1-zhongjun@sangfor.com.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions