Bug 1264258
| Summary: | Guest's time stops with option clock=vm when guest is paused | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Xujun Ma <xuma> |
| Component: | qemu-kvm-rhev | Assignee: | Laurent Vivier <lvivier> |
| Status: | CLOSED ERRATA | QA Contact: | Xujun Ma <xuma> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | dgibson, huding, juzhang, knoel, lvivier, michen, mrezanin, mtosatti, ngu, qzhang, virt-maint, xfu, xuma, zhengtli |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-rhev-2.8.0-4.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 23:29:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Xujun Ma
2015-09-18 03:24:44 UTC
Deferring to 7.3 For my test on following host/guest sw versions, the guest hwclock really stops WHILE the guest system time does not stop as that described in the bug. Host kernel: 3.10.0-316.el7.ppc64le Guest kernel: 3.10.0-316.el7.ppc64 Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-25.el7.ppc64le Just a note: This happens because date seems to use the CPU Time Base Register which is not stopped (it is copied directly from the host). hwclock works correctly, as it uses the RTAS call "get-time-of-day". "date" on a TCG mode guest works too as the TBR is emulated. Ah, that's a good point. Technically the qemu option only affects the RTC which is already behaving correctly. So, the question is, is there a related option that will affect runtime time sources like the timebase, and if so how do we implement it. I think we already have some support for virtualizing the timebase in the kernel (to handle migration and some other edge cases). Xujun Ma, Can you confirm that on x86 the guest time _does_ stop when the guest is paused? Does this change when clock=host is supplied? (In reply to David Gibson from comment #6) > Xujun Ma, > > Can you confirm that on x86 the guest time _does_ stop when the guest is > paused? the time of x86 guest can stop when guest is paused with option "rtc base=utc,clock=vm " Does this change when clock=host is supplied? the time of x86 guest can stop when guest is paused with option "rtc base=utc,clock=host " Xujun Ma, Thanks for the clarifications. * The -rtc options don't make a difference here - that makes sense, since we're discussing the system time (derived from timebase) rather than the real time clock. Our behaviour is different from x86, but TBH, I think the ppc64 behaviour is more correct - system time continues to track wall-clock time, even when the guest is paused. Unless someone has a compelling reason that stopping the clock during pause is a good idea, I'm inclined to close this as NOTABUG. (In reply to David Gibson from comment #8) > Xujun Ma, > > Thanks for the clarifications. > > * The -rtc options don't make a difference here - that makes sense, since > we're discussing the system time (derived from timebase) rather than the > real time clock. > > Our behaviour is different from x86, but TBH, I think the ppc64 behaviour is > more correct - system time continues to track wall-clock time, even when the > guest is paused. > > Unless someone has a compelling reason that stopping the clock during pause > is a good idea, I'm inclined to close this as NOTABUG. Based on above comment, I plan to change the hardware to x86_64 and involve the developer in x86 side to have a look. Since the current behaviour are different between the two platform. Qunfang, The system timekeeping mechanisms are different between x86 and ppc64, so it may not be feasibly to have the same behaviour here. Still, it's at worth passing over to the x86 people for an assessment. I'm reassigning to default to get their attention. (In reply to David Gibson from comment #10) > Qunfang, > > The system timekeeping mechanisms are different between x86 and ppc64, so it > may not be feasibly to have the same behaviour here. Still, it's at worth > passing over to the x86 people for an assessment. I'm reassigning to > default to get their attention. David, Agree with you, will wait for x86 developer to have a look and confirm before we close it. (In reply to David Gibson from comment #8) > Xujun Ma, > > Thanks for the clarifications. > > * The -rtc options don't make a difference here - that makes sense, since > we're discussing the system time (derived from timebase) rather than the > real time clock. > > Our behaviour is different from x86, but TBH, I think the ppc64 behaviour is > more correct - system time continues to track wall-clock time, even when the > guest is paused. > > Unless someone has a compelling reason that stopping the clock during pause > is a good idea, I'm inclined to close this as NOTABUG. https://patchwork.ozlabs.org/patch/252455/ kvmclock should not count while vm is paused, because: 1) if the vm is paused for long periods, timekeeping math can overflow while converting the (large) clocksource delta to nanoseconds. 2) Users rely on CLOCK_MONOTONIC to count run time, that is, time which OS has been in a runnable state (see CLOCK_BOOTTIME). Change kvmclock driver so as to save clock value when vm transitions from runnable to stopped state, and to restore clock value from stopped to runnable transition. -------------- So if PowerPC timekeeping code can overflow after reading a large delta from a clocksource, then counting of the clock should stop. Deferring to 7.4 David, do you think we need to implement on POWER the solution described in comment #12 ? Laurent, I discussed this with Paulus today. We're not sure if (1) applies for powerpc, but (2) would seem to apply universally. So, yes, I think we do need a fix similar to the kvmclock one for Power. Specifically, after the pause, we'll need to recalculate the correct offset between guest and host timebase to result in ~0 time change in the guest, that offset can then be set into KVM with the SET_ONE_REG interface. We should be able to adapt the code used to set the TB offset on an incoming migration for this purpose. What I'm less clear on is how we distinguish between a "real", user requested pause that could last indefinitely and a pause due to other activity (e.g. migration downtime, or something slow that needs to be processed in qemu). The latter should not pause the clock, obviously, or the guest clock will drift unpredictably. I'm hoping the kvmclock patch Marcelo points to will provide some clues for this. Btw, best be careful that the behaviour remains consistent between KVM and TCG guests. For KVM we need to explicitly update a KVM pseudo-register which controls the delta between guest and host timebase (the delta is applied to the real CPU timebase register at guest entry/exit). For TCG, IIRC, the timebase value is computed at mftb() time. So for that we'd need to make sure it's computed according to the VM-relative clock rather than the host-relative clock. I've sent a patch upstream, trying to port i386 patch (from comment #12): http://patchwork.ozlabs.org/patch/720656/ Fix included in qemu-kvm-rhev-2.8.0-4.el7 Reproduce this issue with old build: qemu-kvm-rhev-2.3.0-23.el7.ppc64le guest:3.10.0-655.el7.test.ppc64le host:3.10.0-653.el7.ppc64le Steps to Reproduce: 1.Boot up a guest with option clock=vm -smp 8,sockets=1,cores=2,threads=4 \ -m 8192 \ -monitor stdio \ -rtc base=utc,clock=vm \ -serial unix:serial,server,nowait \ -nodefaults \ -boot menu=on \ -vnc :0 \ -vga virtio \ -device virtio-scsi-pci,bus=pci.0,addr=0x5 \ -device scsi-hd,id=scsi-hd0,drive=scsi-hd-dr0,bootindex=0 \ -drive file=RHEL-7.4.qcow2,if=none,id=scsi-hd-dr0,format=qcow2,cache=none \ -device scsi-cd,id=scsi-cd0,drive=scsi-cd-dr0,bootindex=1 \ -drive file=RHEL-7.4-20170330.1-Server-ppc64le-dvd1.iso,if=none,id=scsi-cd-dr0,readonly=on,format=raw,cache=none \ -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ 2.check time in guest #date 3.stop guest immediately in hmp then wait a minute (qemu)stop 4.continue guest in hmp then show time in guest (qemu)c #date Actual results: Guest's time doesn't stop when guest is paused. Verified this issue with latest build: qemu-kvm-rhev-2.9.0-1.el7.ppc64le guest:3.10.0-655.el7.test.ppc64le host:3.10.0-653.el7.ppc64le Steps to verify: The same steps as above Actual results: Guest's time stop when guest is paused. Base the results above,the bug has been fixed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 |