This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 978109 - kvmclock: S4-resume should sync system time from RTC (to mirror boot)
kvmclock: S4-resume should sync system time from RTC (to mirror boot)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Marcelo Tosatti
Virtualization Bugs
: Reopened
Depends On:
Blocks: Virt-S3/S4-7.0
  Show dependency treegraph
 
Reported: 2013-06-25 22:00 EDT by FuXiangChun
Modified: 2013-12-24 00:25 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-20 17:06:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description FuXiangChun 2013-06-25 22:00:03 EDT
Description of problem:
As subject, Boot Rhe6.4 guest with -rtc "base="2006-06-17",clock=host,driftfix=slew" or "-rtc base="2006-06-17",clock=vm,driftfix=slew", then do S4 inside guest. hardware clock(hwclock) will jump backward after the guest resumed.

Version-Release number of selected component (if applicable):
host:
qemu-kvm-1.5.0-2.el7.x86_64
3.7.0-0.34.el7.x86_64
guest:
rhel6.4

How reproducible:
100%

Steps to Reproduce:
1./usr/libexec/qemu-kvm -M pc-i440fx-1.5 -cpu Opteron_G2 -enable-kvm -m 2048 -smp 4,sockets=2,cores=1,threads=1,maxcpus=254 -name timer-device -uuid a51eb497-bfd7-47c0-8b5b-0853716e3ce6  -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial=QEMU-DISK1 -device virtio-blk-pci,drive=drive-system-disk,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:1d:b2,addr=0x5,bootindex=2 -device virtio-balloon-pci,id=ballooning,addr=0x6 -qmp tcp:0:5555,server,nowait -k en-us -boot menu=on -vnc :2 -monitor stdio -serial unix:/tmp/ttyS0,server,nowait -rtc base="2006-06-17",clock=host,driftfix=slew

2.execute "ntpdate clock.redhat.com" inside guest and host
 
3.check guest clock source
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
kvm-clock

4.query hwclock inside guest via this small script
while true;do hwclock;sleep 1;done

5. do S4 inside guest
echo disk >/sys/power/state

Actual results:
will output this result from step 4 after guest resumed
  Sat 17 Jun 2006 08:02:56 AM CST  -0.994621 seconds
  Sat 17 Jun 2006 08:02:58 AM CST  -0.994574 seconds
  Sat 17 Jun 2006 08:03:00 AM CST  -0.994502 seconds
  Sat 17 Jun 2006 08:03:02 AM CST  -0.994749 seconds
  Sat 17 Jun 2006 08:03:04 AM CST  -0.994338 seconds
  Sat 17 Jun 2006 08:03:06 AM CST  -0.994428 seconds
  Sat 17 Jun 2006 08:03:08 AM CST  -0.994297 seconds
  Sat 17 Jun 2006 08:03:10 AM CST  -0.994269 seconds
  Sat 17 Jun 2006 08:03:12 AM CST  -0.994236 seconds
**Sat 17 Jun 2006 08:00:23 AM CST  -0.753766 seconds**
  Sat 17 Jun 2006 08:00:25 AM CST  -0.960243 seconds
  Sat 17 Jun 2006 08:00:27 AM CST  -0.994099 seconds
  Sat 17 Jun 2006 08:00:29 AM CST  -0.994421 seconds
  Sat 17 Jun 2006 08:00:31 AM CST  -0.994426 seconds
  Sat 17 Jun 2006 08:00:33 AM CST  -0.994528 seconds
  Sat 17 Jun 2006 08:00:35 AM CST  -0.994424 seconds
  Sat 17 Jun 2006 08:00:37 AM CST  -0.994580 seconds

Expected results:
jump forward current time after S4

Additional info:
rhel7.0 guest don't hit this issue
Comment 2 FuXiangChun 2013-06-26 00:45:11 EDT
Re-test this issue with accurate clock base="2013-06-26T11:11:11".  after the guest resumed from S4, hardware clock is still initial time, system time is current time. 
Root cause is that system time don't sync guest hardware time after the guest resumed from S4.

The following are detailed test steps.
host:
# uname -r
3.10.0-0.rc6.62.el7.x86_64
# rpm -qa|grep qemu
qemu-kvm-1.5.0-2.el7.x86_64

guest:
rhel6.4
rhel7.0

1. Boot guest with "-rtc base="2013-06-26T11:11:11",clock=host,driftfix=slew" and without network
/usr/libexec/qemu-kvm -M pc-i440fx-1.5 -cpu Opteron_G2 -enable-kvm -m 2048 -smp 4,sockets=2,cores=1,threads=1,maxcpus=254 -name timer-device -uuid a51eb497-bfd7-47c0-8b5b-0853716e3ce6  -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial=QEMU-DISK1 -device virtio-blk-pci,drive=drive-system-disk,id=system-disk,bootindex=1 -device virtio-balloon-pci,id=ballooning,addr=0x6 -qmp tcp:0:5555,server,nowait -k en-us -boot menu=on -vnc :2 -monitor stdio -serial unix:/tmp/ttyS0,server,nowait -net none -rtc base="2013-06-26T11:11:11",clock=host,driftfix=slew

2. check system time and hardware time inside guest
# date && hwclock
Wed Jun 26 19:12:16 CST 2013
Wed 26 Jun 2013 07:12:17 PM CST  -0.220379 seconds

3. do S4 inside guest
#pm-hibernate

4. resume guest 

5. re-check system time and hardware time inside guest
# date && hwclock
Wed Jun 26 19:17:30 CST 2013
Wed 26 Jun 2013 07:12:04 PM CST  -0.300788 seconds

so guest system time don't sync hardware time after guest resumed from S4. 

In addition, If boot rhel7.0 guest without network. it will hit the same issue.

If base=utc, we will get the following result.
before S4.
# date && hwclock
Wed Jun 26 12:13:05 CST 2013
Wed 26 Jun 2013 12:13:05 PM CST  -0.063998 seconds

after S4
# date && hwclock
Wed Jun 26 12:14:57 CST 2013
Wed 26 Jun 2013 12:14:58 PM CST  -0.395743 seconds
Comment 3 Marcelo Tosatti 2013-06-30 12:45:10 EDT
This is expected: starting the guest with "-rtc base="2013-06-26T11:11:11",clock=host,driftfix=slew" tells QEMU that the RTC clock should start counting at the same time in both instances.
Comment 4 FuXiangChun 2013-07-01 06:47:23 EDT
Re-test this issue with accurate clock base="2013-06-26T11:11:11".  after the guest resumed from S4, hardware clock is still initial(2013-06-26T11:11:11) time, however, system time is synced to the host time.  (I think guest system time should sync guest's hardware time after S4. so that the system time is initial time(2013-06-26T11:11:11) as well after S4, or guest's hardware time is synced to the host time soon after S4).  

so, I reopen this bug.  If I am wrong, please correct me. any comment is welcome.
Comment 6 FuXiangChun 2013-07-02 01:55:54 EDT
Tested this issue with https://brewweb.devel.redhat.com/taskinfo?taskID=5976858

host and guest kernel version:
3.10.0-0.rc7.64.el7bz978109.x86_64

Boot guest with -rtc base="2013-06-26T11:11:11",clock=host,driftfix=slew

1.Before S4, check system time and hardware time inside guest:
# hwclock
Wed 26 Jun 2013 07:14:00 PM CST  -0.457906 seconds

# date
Wed Jun 26 19:14:05 CST 2013

2.After S4, re-check system time and hardware inside guest:
# hwclock
Wed 26 Jun 2013 07:11:36 PM CST  -0.121755 seconds
# date
date
Wed Jun 26 19:14:53 CST 2013

result: after S4, guest hardware time is still initial time, the system isn't initial time. 

so the kernel don't fix this issue.
Comment 10 FuXiangChun 2013-12-17 09:53:21 EST
I tested three times with base="2013-06-26T11:11:11",clock=host,driftfix=slew and kernel 3.10.0-52.el7bz978109rtcS4.x86_64(guest and host).

result:
before s4
# hwclock && date
host hardware and system time
Tue 17 Dec 2013 10:39:15 PM CST  -0.297754 seconds
Tue Dec 17 22:39:15 CST 2013

guest hardware and system time
# hwclock && date
wed 26 Jun 2013 07:11:46 PM CST -0.739115 seconds  
web Jun 26 19:11:46 CST 2013

after resume from s4
host hardware and system time
# hwclock && date
Tue 17 Dec 2013 10:40:05 PM CST  -0.219559 seconds
Tue Dec 17 22:40:05 CST 2013

guest hardware and system time
# hwclock && date
wed 26 Jun 2013 07:11:32 PM CST -0.229227 seconds 
web Jun 26 19:11:59 CST 2013

so guest system time don't synchronizes from RTC after resuming.

Note You need to log in before you can comment on or make changes to this bug.