Hi Radim,
On 2017/6/13 4:03, Radim Krčmář wrote:
2017-06-12 21:30+0800, Jay Zhou:
Guest using kvmclock will be hanged when migrating from unstable
tsc host to stable tsc host occasionally.
Sometimes, the tsc timestamp saved at the source side will be
backward when the guest stopped, and this value is transferred
to the destination side. The guest at the destination side thought
kvmclock is stable, so the protection mechanism against time
going backwards is not used.
When the first time vcpu0 enters the guest at the destination
side to update the wall clock, the result of
pvclock_clocksource_read will be backward occasionally,
which results in the wall clock drift.
Signed-off-by: Jay Zhou <jianjay.zhou@xxxxxxxxxx>
---
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
if (running) {
struct kvm_clock_data data = {};
+ uint8_t flags_at_migration;
/*
* If the host where s->clock was read did not support reliable
* KVM_GET_CLOCK, read kvmclock value from memory.
*/
if (!s->clock_is_reliable) {
'clock_is_reliable = true' on all newer KVMs (v4.9+), so I don't see a
reason to add a feature that can't be used.
After rereading the codes, yes, I agree. Sorry to disturb.
- uint64_t pvclock_via_mem = kvmclock_current_nsec(s);
+ uint64_t pvclock_via_mem = kvmclock_current_nsec(s,
+ &flags_at_migration);
kvmclock_current_nsec() was introduced to work around the problem with
backward time, so we should understand why it returns a time that is
backwards if we want to do something for old KVMs ...
Is pvclock_via_mem < s->clock?
Please see the other thread I replied to you when the bug occured.
Regards,
Jay Zhou
