Skip to contentSkip to conversation

KVM: x86: switch KVMCLOCK base to CLOCK_MONOTONIC_RAW

PATCH Marcelo Tosatti 1 participant 1 message Oct 23, 2019 4 messages not in the archive KVM

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 31 lines · Marcelo Tosatti
Quoted 19 lines · Paolo Bonzini
Quoted 18 lines · Marcelo Tosatti

Commit 0bc48bea36d1 ("KVM: x86: update master clock before computing kvmclock_offset") switches the order of operations to avoid the conversion

TSC (without frequency correction) ->
system_timestamp (with frequency correction),

which might cause a time jump.

However, it leaves any other masterclock update unsafe, which includes, at the moment:

* HV_X64_MSR_REFERENCE_TSC MSR write.
* TSC writes.
* Host suspend/resume.

Avoid the time jump issue by using frequency uncorrected CLOCK_MONOTONIC_RAW clock.

Quoted 8 lines
Quoted 4 lines

Its the guests time keeping software responsability to track and correct a reference clock such as UTC.

What happens across migration?

Paolo

You mean between

Quoted 7 lines

frequency corrected host -> frequency uncorrected host

And vice-versa?

I'll check NTP's/Chrony's behaviour and let you know.

Thanks

They will measure and adjust their frequency corrections (which is necessary anyway due to temperature variations for example).

http://doc.ntp.org/4.1.0/ntpd.htm

Frequency Discipline

The ntpd behavior at startup depends on whether the frequency file, usually ntp.drift, exists. This file contains the latest estimate of clock frequency error. When the ntpd is started and the file does not exist, the ntpd enters a special mode designed to quickly adapt to the particular system clock oscillator time and frequency error. This takes approximately 15 minutes, after which the time and frequency are set to nominal values and the ntpd enters normal mode, where the time and frequency are continuously tracked relative to the server. After one hour the frequency file is created and the current frequency offset written to it. When the ntpd is started and the file does exist, the ntpd frequency is initialized from the file and enters normal mode immediately. After that the current frequency offset is written to the file at hourly intervals.