summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorJunlian Bell <zhongjun@sangfor.com.cn>2016-09-26 20:41:01 +0800
committerPaolo Bonzini <pbonzini@redhat.com>2016-10-04 10:00:25 +0200
commit3cf294eebc98da6e2ff7976fcdf6a9b41984840e (patch)
tree62acad2b2be2151d5c65c38ce93344902204891d /docs
parent1d5b128cbeeab638f772e88674f22e36b1b024e5 (diff)
downloadqemu-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