Re: [Qemu-devel] [PATCH]MC146818 RTC: coordinate guest clock base to destination host after migration

["zhongjun@sangfor.com.cn" <zhongjun@sangfor.com.cn>]

Hi, Paolo
The reason that use rtc_flush_time/rtc_adjust_timebase pairs instead of rtc_update_time/rtc_set_time  is a trick.
what all we do is to coordinate the base point of time line for guest on a new host.  So, we don't flush realtime
of the guest when it's stopped into cmos, but only convert vector [base_rtc, last_update] into cmos. 
Additionally ,  with a new function rtc_flush_time,  we can do some special adjustment to reduce deviation of
guest time caused by migration. because granularity of cmos time is second, so maximum deviation of time base
transfer via cmos is one second.
        guest_sec = (guest_nsec + NANOSECONDS_PER_SECOND/2)/ NANOSECONDS_PER_SECOND;
Adjusted by this statement, the deviation reduce to half a second.
On the other hand, the problem of rtc_update_time is it add time up plus s->offset, then when rtc_set_time 
recalculate new last_update, it actually introduce s->offset into base vector [base_rtc, last_update].  further, 
when guest continue to run and read realtime from cmos, rtc_update_time will add s->offset again, so s->offset
is doubled. 

Thanks!

below is full options.

./qemu \
-id 1738826302644 \
-chardev socket,id=qmp,host=200.200.100.112,port=5111,server,nowait \
-mon chardev=qmp,mode=control \
-vnc 0.0.0.0:30 \
-enable-kvm \
-pidfile /var/run/qemu-server/1738826302644.pid \
-name win2008x64_Sangfor123clone \
-cpu core2duo,hv_spinlocks=0xffff,hv_relaxed,hv_time,hv_vapic,+sse4.1,+sse4.2,+x2apic,+pcid,+pdcm,+xtpr,+ht,+ss,+acpi,+ds \
-nodefaults \
-vga cirrus \
-no-hpet \
-k en-us \
-boot menu=on,splash-time=20000,ostype=windows,reboot-timeout=5000 \
-smp sockets=1,cores=2 \
-m 4096 \
-rtc driftfix=slew,clock=rt,base=localtime \
-global kvm-pit.lost_tick_policy=discard \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=1 \
-device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f \
-device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e \
-usb \
-device usb-tablet,id=input0 \
-hda /home/test/img/winxp.qcow2 \
-bios /sf/share/kvm/bios.bin \
-machine mem-merge=off \
-post win2008x64_Sangfor123clone

---

>   On 20/09/2016 09:19, zhongjun@sangfor.com.cn wrote:
>   > 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.
>    
>   But last_update is not a monotonic tick, it's basically gettimeofday
>   unless you're using the "-rtc clock=..." option.
>    
>   > +static void rtc_flush_time(RTCState *s)
>   > +{
>   > +    struct tm ret;
>   > +    time_t guest_sec;
>   > +    int64_t guest_nsec;
>   > +    uint64_t guest_clock = qemu_clock_get_ns(rtc_clock);
>   > +
>   > +    guest_nsec = s->base_rtc * NANOSECONDS_PER_SECOND
>   > +                 + guest_clock - s->last_update;
>   > +    guest_sec = (guest_nsec + NANOSECONDS_PER_SECOND/2)/ NANOSECONDS_PER_SECOND;
>   > +    gmtime_r(&guest_sec, &ret);
>   > +
>   > +    rtc_set_cmos(s, &ret);
>    
>   This should be just rtc_update_time(s).
>    
>   Similarly:
>    
>   >
>   > +    rtc_get_time(s, &tm);
>   > +    diff = mktimegm(&tm) - s->base_rtc;
>   > +    assert(diff >= 0);
>   > +    s->last_update = qemu_clock_get_ns(rtc_clock)
>   > +                    - diff * NANOSECONDS_PER_SECOND;
>    
>   This should be rtc_set_time.
>    
>   However, there are two problems with this approach.  First, if you
>   migrate old QEMU to new QEMU, the new QEMU expects to have an up-to-date
>   s->base_rtc, while old QEMU provided an old QEMU.  Second, every
>   migration will delay the RTC by a few tenths of a second.  So the call
>   to rtc_set_time should be conditional on rtc_clock == QEMU_CLOCK_REALTIME.
>    
>   Paolo