On Fri, 2023-09-29 at 13:15 -0700, Dongli Zhang wrote: > > > We want more frequent KVM_REQ_MASTERCLOCK_UPDATE. > > This is because: > > 1. The vcpu->hv_clock (kvmclock) is based on its own mult/shift/equation. > > 2. The raw monotonic (tsc_clocksource) uses different mult/shift/equation. > > 3. As a result, given the same rdtsc, kvmclock and raw monotonic may return > different results (this is expected because they have different > mult/shift/equation). > > 4. However, the base in kvmclock calculation (tsc_timestamp and system_time) > are derived from raw monotonic clock (master clock) That just seems wrong. I don't mean that you're incorrect; it seems *morally* wrong. In a system with X86_FEATURE_CONSTANT_TSC, why would KVM choose to use a *different* mult/shift/equation (your #1) to convert TSC ticks to nanoseconds than the host CLOCK_MONOTONIC_RAW does (your #2). I understand that KVM can't track the host's CLOCK_MONOTONIC, as it's adjusted by NTP. But CLOCK_MONOTONIC_RAW is supposed to be consistent. Fix that, and the whole problem goes away, doesn't it? What am I missing here, that means we can't do that? Alternatively... with X86_FEATURE_CONSTANT_TSC, why do the sync at all? If KVM wants to decide that the TSC runs at a different frequency to the frequency that the host uses for CLOCK_MONOTONIC_RAW, why can't KVM just *stick* to that?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
