Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock periodically

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]