Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Thu, 30 Nov 2023 17:52:12 -0800
In-Reply-To: <20231018195638.1898375-1-seanjc@google.com>
Mime-Version: 1.0
References: <20231018195638.1898375-1-seanjc@google.com>
Message-ID: <170137723293.662627.9568255433684903794.b4-ty@google.com>
Subject: Re: [PATCH] KVM: x86: Don't unnecessarily force masterclock update on
 vCPU hotplug
From:   Sean Christopherson <seanjc@google.com>
To:     Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Dongli Zhang <dongli.zhang@oracle.com>,
        David Woodhouse <dwmw2@infradead.org>
Content-Type: text/plain; charset="utf-8"
Precedence: bulk

On Wed, 18 Oct 2023 12:56:38 -0700, Sean Christopherson wrote:
> Don't force a masterclock update when a vCPU synchronizes to the current
> TSC generation, e.g. when userspace hotplugs a pre-created vCPU into the
> VM.  Unnecessarily updating the masterclock is undesirable as it can cause
> kvmclock's time to jump, which is particularly painful on systems with a
> stable TSC as kvmclock _should_ be fully reliable on such systems.
> 
> The unexpected time jumps are due to differences in the TSC=>nanoseconds
> conversion algorithms between kvmclock and the host's CLOCK_MONOTONIC_RAW
> (the pvclock algorithm is inherently lossy).  When updating the
> masterclock, KVM refreshes the "base", i.e. moves the elapsed time since
> the last update from the kvmclock/pvclock algorithm to the
> CLOCK_MONOTONIC_RAW algorithm.  Synchronizing kvmclock with
> CLOCK_MONOTONIC_RAW is the lesser of evils when the TSC is unstable, but
> adds no real value when the TSC is stable.
> 
> [...]

Applied to kvm-x86 misc, thanks!

[1/1] KVM: x86: Don't unnecessarily force masterclock update on vCPU hotplug
      https://github.com/kvm-x86/linux/commit/c52ffadc65e2

--
https://github.com/kvm-x86/linux/tree/next