From nobody Tue Aug 25 23:00:23 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=infradead.org ARC-Seal: i=1; a=rsa-sha256; t=1783113762; cv=none; d=zohomail.com; s=zohoarc; b=mgB1lx6kwdAYph3i9XnadaFJBhKkCXca84XJA34B20NWka7AiL+KLO69eTm5jGcK1H+r8WDyWjYYMrl99Vugn2g8dRPt+fFOT9ozq+2WmUAX1FOlE3WQwilZuOqmhBh+zfDnBsxEeQ3v2s1RZU0gAtCeVVxQKS3x+/KEiMtioM8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1783113762; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=LCPHKocQxei12eLOnimwDSC7Gdxv3emgr2rZMstPsfQ=; b=bRKnYgFHE+LjNrdQrIKs00tlpEBWVrfzuDznqB4kn7oxTnDOkT8te8mywTiGQA77w1bfHrWuN5NxnXHhW54IRLFL7XXC/ZO3uDDzdO6SCs2JAsIuOyg+T6UuABEOq77bsZN0RkSRTBvCpOHpnF3DxViwM8w/Ci/MnhjbZ+UWUmY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1783113762127425.0007100073825; Fri, 3 Jul 2026 14:22:42 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1353763.1609555 (Exim 4.92) (envelope-from ) id 1wflKy-0008BG-9m; Fri, 03 Jul 2026 21:22:16 +0000 Received: by outflank-mailman (output) from mailman id 1353763.1609555; Fri, 03 Jul 2026 21:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wflKy-0008B2-6D; Fri, 03 Jul 2026 21:22:16 +0000 Received: by outflank-mailman (input) for mailman id 1353763; Fri, 03 Jul 2026 21:22:14 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wflKw-00081M-88 for xen-devel@lists.xenproject.org; Fri, 03 Jul 2026 21:22:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wflKv-00CeeP-LH; Fri, 03 Jul 2026 23:22:13 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a4827de-bab6-0a2a0a5309dd-0a2a450adcec-24 for ; Fri, 03 Jul 2026 23:22:13 +0200 Received: from [90.155.50.34] (helo=casper.infradead.org) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a482805-e40e-0a2a450a0019-5a9b3222ce60-3 for ; Fri, 03 Jul 2026 23:22:13 +0200 Received: from [2001:8b0:10b:1::425] (helo=i7.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wflKX-0000000AsYD-0x2z; Fri, 03 Jul 2026 21:21:49 +0000 Received: from dwoodhou by i7.infradead.org with local (Exim 4.99.2 #2 (Red Hat Linux)) id 1wflKX-00000001RPP-0bzt; Fri, 03 Jul 2026 22:21:49 +0100 X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=casper.20170209 header.d=infradead.org header.i="@infradead.org" header.h="Sender:Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To: From:Reply-To:Cc:Content-ID:Content-Description; bh=LCPHKocQxei12eLOnimwDSC7Gdxv3emgr2rZMstPsfQ=; b=D+gxe+zOcTheHMuzWnvdCppNWA 57JVykAHl5rRTwt63XLCRD1vkYCu3NQBErzPcDEbuP+MaahyYUw5hq3EwgT7E4w2h7Gg0Ma1b5I9c y+FhSO1tI4GXlHfRW+zlB1kpu6M0vVZhLe9024hdHZX3BeH+AbDSkFNkPcop8uZEzpFkwZZTViDED XNcIi+iHLsu+wlkRd+qUOzLAXeurJLINvTyk2DBnlnB/8mRDQeMAjew2fmG/MNXpKG+17Z+JFWmfB M+I6BAQ6bxpzkaSzDdefvG7Z1bLT2dKVd2DTwpsBwrI0PN2j3OaH1YdS6A6i80wBBLY9y/hrMp1mS kde8DTaQ==; From: David Woodhouse To: Paolo Bonzini , Jonathan Corbet , Shuah Khan , Sean Christopherson , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Vitaly Kuznetsov , Juergen Gross , Boris Ostrovsky , David Woodhouse , Paul Durrant , Jonathan Cameron , Sascha Bischoff , Marc Zyngier , Joey Gouly , Jack Allister , Dongli Zhang , joe.jin@oracle.com, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kselftest@vger.kernel.org Subject: [PATCH v6 24/36] KVM: x86: Factor out kvm_use_master_clock() Date: Fri, 3 Jul 2026 22:18:03 +0100 Message-ID: <20260703212145.343527-25-dwmw2@infradead.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260703212145.343527-1-dwmw2@infradead.org> References: <20260703212145.343527-1-dwmw2@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: David Woodhouse X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-purgate-ID: tlsNG-4011c0/1783113733-D6B3CDDE-1712DCFB/0/0 X-purgate-type: clean X-purgate-size: 4292 X-ZohoMail-DKIM: pass (identity @infradead.org) X-ZM-MESSAGEID: 1783113764544158500 From: David Woodhouse Both kvm_track_tsc_matching() and pvclock_update_vm_gtod_copy() make a decision about whether the KVM clock should be in master clock mode. They used *different* criteria for the decision though. This isn't really a problem; it only has the potential to cause unnecessary invocations of KVM_REQ_MASTERCLOCK_UPDATE if the masterclock was disabled due to TSC going backwards, or the guest using the old MSR. But it isn't pretty. Factor the decision out to a single function. And document the historical reason why it's disabled for guests that use the old MSR_KVM_SYSTEM_TIME. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant --- arch/x86/kvm/x86.c | 40 ++++++++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 3a651f5ce2d2..f8883c3b8ed2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2638,11 +2638,30 @@ static inline bool gtod_is_based_on_tsc(int mode) { return mode =3D=3D VDSO_CLOCKMODE_TSC || mode =3D=3D VDSO_CLOCKMODE_HVCLO= CK; } -#endif + +static bool kvm_use_master_clock(struct kvm *kvm) +{ + struct kvm_arch *ka =3D &kvm->arch; + + /* + * The 'old kvmclock' check is a workaround (from 2015) for a + * SUSE 2.6.16 kernel that didn't boot if the system_time in + * its kvmclock was too far behind the current time. So the + * mode of just setting the reference point and allowing time + * to proceed linearly from there makes it fail to boot. + * Despite that being kind of the *point* of the way the clock + * is exposed to the guest. By coincidence, the offending + * kernels used the old MSR_KVM_SYSTEM_TIME, which was moved + * only because it resided in the wrong number range. So the + * workaround is activated for *all* guests using the old MSR. + */ + return ka->all_vcpus_matched_freq && + !ka->backwards_tsc_observed && + !ka->boot_vcpu_runs_old_kvmclock; +} =20 static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclo= ck) { -#ifdef CONFIG_X86_64 struct kvm_arch *ka =3D &vcpu->kvm->arch; struct pvclock_gtod_data *gtod =3D &pvclock_gtod_data; bool prev_matched_tsc =3D ka->all_vcpus_matched_tsc; @@ -2680,7 +2699,7 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *v= cpu, bool update_mclock) * are fine =E2=80=94 each vCPU's pvclock has its own tsc_timestamp that * accounts for its offset. */ - bool use_master_clock =3D ka->all_vcpus_matched_freq && + bool use_master_clock =3D kvm_use_master_clock(vcpu->kvm) && gtod_is_based_on_tsc(gtod->clock.vclock_mode); =20 /* @@ -2695,8 +2714,11 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *= vcpu, bool update_mclock) trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc, atomic_read(&vcpu->kvm->online_vcpus), ka->use_master_clock, gtod->clock.vclock_mode); -#endif } +#else +static inline void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, + bool new_generation) {} +#endif =20 /* * Multiply tsc by a fixed point number represented by ratio. @@ -3210,10 +3232,9 @@ static void pvclock_update_vm_gtod_copy(struct kvm *= kvm) #ifdef CONFIG_X86_64 struct kvm_arch *ka =3D &kvm->arch; int vclock_mode; - bool host_tsc_clocksource, vcpus_matched; + bool host_tsc_clocksource; =20 lockdep_assert_held(&kvm->arch.tsc_write_lock); - vcpus_matched =3D ka->all_vcpus_matched_freq; =20 /* * If the host uses TSC clock, then passthrough TSC as stable @@ -3223,9 +3244,8 @@ static void pvclock_update_vm_gtod_copy(struct kvm *k= vm) &ka->master_kernel_ns, &ka->master_cycle_now); =20 - ka->use_master_clock =3D host_tsc_clocksource && vcpus_matched - && !ka->backwards_tsc_observed - && !ka->boot_vcpu_runs_old_kvmclock; + ka->use_master_clock =3D host_tsc_clocksource && + kvm_use_master_clock(kvm); =20 if (ka->use_master_clock) { u64 tsc_hz; @@ -3253,7 +3273,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *k= vm) =20 vclock_mode =3D pvclock_gtod_data.clock.vclock_mode; trace_kvm_update_master_clock(ka->use_master_clock, vclock_mode, - vcpus_matched); + ka->all_vcpus_matched_freq); #endif } =20 --=20 2.54.0