Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Mon, 2 Oct 2023 23:06:07 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Sean Christopherson <seanjc@google.com>
Cc:     Dongli Zhang <dongli.zhang@oracle.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Joe Jin <joe.jin@oracle.com>, x86@kernel.org,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com
Subject: Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock
 periodically
Message-ID: <20231002210607.GD27267@noisy.programming.kicks-ass.net>
References: <20230926230649.67852-1-dongli.zhang@oracle.com>
 <377d9706-cc10-dfb8-5326-96c83c47338d@oracle.com>
 <36f3dbb1-61d7-e90a-02cf-9f151a1a3d35@oracle.com>
 <ZRWnVDMKNezAzr2m@google.com>
 <a461bf3f-c17e-9c3f-56aa-726225e8391d@oracle.com>
 <884aa233ef46d5209b2d1c92ce992f50a76bd656.camel@infradead.org>
 <ZRrxtagy7vJO5tgU@google.com>
 <a8479764-34a1-334f-3865-c01325d772d9@oracle.com>
 <ZRsJiuKdXtWos_Xh@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZRsJiuKdXtWos_Xh@google.com>
Precedence: bulk

On Mon, Oct 02, 2023 at 11:18:50AM -0700, Sean Christopherson wrote:
> +PeterZ
> 
> Thomas and Peter,
> 
> We're trying to address an issue where KVM's paravirt kvmclock drifts from the
> host's TSC-based monotonic raw clock because of historical reasons (at least, AFAICT),
> even when the TSC is constant.  Due to some dubious KVM behavior, KVM may sometimes
> re-sync kvmclock against the host's monotonic raw clock, which causes non-trivial
> jumps in time from the guest's perspective.
> 
> Linux-as-a-guest demotes all paravirt clock sources when the TSC is constant and
> nonstop, and so the goofy KVM behavior isn't likely to affect the guest's clocksource,
> but the guest's sched_clock() implementation keeps using the paravirt clock.
> 
> Irrespective of if/how we fix the KVM host-side mess, using a paravirt clock for
> the scheduler when using a constant, nonstop TSC for the clocksource seems at best
> inefficient, and at worst unnecessarily complex and risky.
> 
> Is there any reason not to prefer native_sched_clock() over whatever paravirt
> clock is present when the TSC is the preferred clocksource? 

I see none, that whole pv_clock thing is horrible crap.

> Assuming the desirable
> thing to do is to use native_sched_clock() in this scenario, do we need a separate
> rating system, or can we simply tie the sched clock selection to the clocksource
> selection, e.g. override the paravirt stuff if the TSC clock has higher priority
> and is chosen?

Yeah, I see no point of another rating system. Just force the thing back
to native (or don't set it to that other thing).