From nobody Sat Jul 25 17:35:17 2026 Received: from forwardcorp1b.mail.yandex.net (forwardcorp1b.mail.yandex.net [178.154.239.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF823420495 for ; Wed, 15 Jul 2026 13:01:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.154.239.136 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784120500; cv=none; b=l1vwLThVAlaiIHQi0TPQNEiLDamWI6KlIPIxM3hO0a7ygB+ROHxpsTcCFhfbpeghSZfB06WPQHIsX2df40rEDgodGs3tGgAd9+Lx8lFBkCCOoKR1R6oNTUm/j8Nt4p/hmSx0VKnVbiowlsZYZzcwSg2gb1iLpNOho6o/wWvxGCs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784120500; c=relaxed/simple; bh=Sf3+s7T3OjPeQI5erpVhX2VrAOIBUYLDQ6HK9Asa/yA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=MoBNTaPz7ooAdGL0Hi/gzyCIBiU299I5n4kC8AJmYsYQj9mJkqVFUk2/H/29BDVI5C32ZUKpPkwsPzFc9fImcFSZa1UzMfAHaDACTi9zx03Gb5YkOaiMjuuDx7RJZDm1kvJW75FFDImOa+CF1WvjwxuW+hU+6NwjOgszOtldDKs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru; spf=pass smtp.mailfrom=yandex-team.ru; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b=sAyA9uD5; arc=none smtp.client-ip=178.154.239.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yandex-team.ru Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="sAyA9uD5" Received: from mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:39a2:0:640:ae2d:0]) by forwardcorp1b.mail.yandex.net (postfix) with ESMTPS id DB373805E6; Wed, 15 Jul 2026 15:59:34 +0300 (MSK) Received: from davydov-max-lin.yandex.net (unknown [2a02:6bf:8011:f00:68a9:dea6:4555:f5cb]) by mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (smtpcorp) with ESMTPSA id 5xP2Rf0a6Ko0-1feBUD6Q; Wed, 15 Jul 2026 15:59:34 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1784120374; bh=BZKeyA03Jtmkontp/4uH5PyVq+8yqBQ8lBgHC612KJY=; h=Message-Id:Date:Cc:Subject:To:From; b=sAyA9uD5Z/VNfQvCrLoy34G8+T5shE6K764nUox8J08Hw0GxyIRueBrg8uaRI+KTi Y8qojjqIzhOBMc/LN43uqmuJNvcvc3bMmi/hIwkEx2bUqrcd9ZtIFNhmNb4DKDP+9L g1D8QephDM235/Pz5Y4qPDpgxsemIdCIaFITbnEE= Authentication-Results: mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Maksim Davydov To: linux-kernel@vger.kernel.org Cc: davydov-max@yandex-team.ru, tglx@kernel.org, mingo@redhat.com, peterz@infradead.org, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com Subject: [PATCH] clocksource: stop monitoring TSC in VMs Date: Wed, 15 Jul 2026 15:59:05 +0300 Message-Id: <20260715125905.104313-1-davydov-max@yandex-team.ru> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It seems that in a virtual machine hardware clocks shouldn't be monitored by software (paravirtualized or emulated) clocks because they have different behaviour. For example, a VM can be live-migrated to another host or it can be paused. Both of them can cause false positive marking of TSC as unstable: w/ kvm-clock: clocksource: Marking clocksource tsc unstable due to frequency skew clocksource: Watchdog kvm-clock interval: 301338133ns clocksource: Clocksource tsc interval: 620070548ns tsc: Marking TSC unstable due to clocksource watchdog clocksource: Switched to clocksource kvm-clock w/o kvm-clock: clocksource: Marking clocksource tsc unstable due to frequency skew clocksource: Watchdog hpet interval: 248411930ns clocksource: Clocksource tsc interval: 480045119ns tsc: Marking TSC unstable due to clocksource watchdog TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc= =3Dunstable'. sched_clock: Marking unstable (302400491443, 145482655)<-(302687230264, -= 141256934) clocksource: Switched to clocksource hpet Both examples were created in the VM with invariant TSC, but without TSC_ADJUST MSR in order to fail check in check_system_tsc_reliable(). So, it is stable enough to be the best clocksource but not reliable enough to be without a watchdog. The reason why TSC can be marked as unstable is the different way of saving and restoring state of clocks. In virtualized environment TSC is a "hardware" clock that QEMU doesn't stop during VM pause. On the other hand, QEMU stops hpet and kvm-clock. So live-migration to paused state (e.g. in order to hot-plug some devices) or short stop+cont can cause divergence of TSC and any other "software" clocks. (The point to have the same behaviour for all clocks will be discussed later in qemu-devel.) Nevertheless, it is important to point out, kvm_clock_read() used to touch watchdog and that prevents false positive marking TSC as unstable, because a hypervisor usually notifies a VM about clocks interference and a guest OS usually checks the appropriate flags. This behaviour was changed in 8739c6811572. But still, this issue has also existed (and now exists) with other clocks. Thus, it seems that the clocksource watchdog has to be disabled for TSC in VMs unless the opposite is explicitly requested by `tsc=3Dwatchdog`. "Hardware" stable TSC is more realible than "software" clocks that usually use host's TSC inside. Fixes: 8739c6811572 ("sched/clock/x86: Mark sched_clock() noinstr") Signed-off-by: Maksim Davydov --- arch/x86/kernel/tsc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index ce10ae4b298b..11b24f0c19bd 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1553,7 +1553,8 @@ void __init tsc_init(void) return; } =20 - if (tsc_clocksource_reliable || tsc_watchdog =3D=3D TSC_WATCHDOG_OFF) + if (tsc_clocksource_reliable || tsc_watchdog =3D=3D TSC_WATCHDOG_OFF || + boot_cpu_has(X86_FEATURE_HYPERVISOR)) tsc_disable_clocksource_watchdog(); =20 clocksource_register_khz(&clocksource_tsc_early, tsc_khz); --=20 2.34.1