From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06DAF40F6EA for ; Fri, 15 May 2026 19:21:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778872880; cv=none; b=dNwBqcsLmXp2UlZUCKuFrw+GK1FhMEEo3bR2jLERjItaj/MkjFJf8RVgr144xBh12fqtifR6GHpSp5zFIqxHSqSaxhQ9Sth3krqY7nDZuyrbJYZnV0u8VJ/VL+OYUGtxsbmnHgugoyPf/QtyrwzvtV3tCEQwIIj4DyPcVjKevP4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778872880; c=relaxed/simple; bh=m/luZgSg5MFPZdvcg1lGftNBA8eVB0LHHzknRLffplY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=d1LfhKDPGVoDRu6E4NXdQIPW9Wcpvfk4+GbIHQlSOhR/mVqtRKDF5TwrNeznKEIkv6ApuYB/5PqhDwqZq6FIdFwfRJ7GwYkWcff5WnIijukV42sZqlKd4tLRZgMXDZoFtC9aaH1IVXa/R1eThgAbzFMfVZO1w+Y8uXdwjimkIXo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=v0VIBiMh; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="v0VIBiMh" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-82f9429f49cso282543b3a.3 for ; Fri, 15 May 2026 12:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778872877; x=1779477677; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=E3je6rXVDqS2RblPlDEIDkn7XwnxqvqokNa5l9m4jL4=; b=v0VIBiMh5rqevqCDBDUERGqZs6DRmjKj5dAde+ysnyuBXGMsYBFwcMPm4Ae4BwaWzF V1qMegse5FUJ474Prgzxxy7ZK3Vn9wBcBkTVN18ReiXHEUxTh8u4Me5wPKW+r8nDE2ZH IYFv443XExQ/ojRk7MRdYkEEf7VmrFKbWMJW3WHc/KAojlYDpUKn1wtwlNU1HHkmyDxG WGnNPHk6Zd1cTSzxoMU0JeTo/3ow2EmBc/f4qm4ztOUOcUjNN4KkDVno7CQTZ3SHQrG9 3AMpXJO5W9+IAJvFrHF3KrBjh/bhVDq+Z9FvvjpDbPbmWV4E2He+bLqy0rK0WuLX0Omo 9cRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778872877; x=1779477677; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E3je6rXVDqS2RblPlDEIDkn7XwnxqvqokNa5l9m4jL4=; b=M4CsSi8zofCkkH8zvxffA31GpjbI6Zeu11TOE0OVmj1uSZXbvG2eZKQnQd2327xgHY Yi2ip2SwWbLI/jJ9yByOnF9cYqfK6TKQC4GRJXoo+0Q/XvZ12E/Y0mu5dcTQU3UstEfT jLhdKXH7d/eyk/yr4eTPi9WuE2eg1Ey3N4dreXi+YEQDW3kb53XIGQainUOASAE3voJ3 8sUpkd+eWWaHF9DEflXxZ9LmhDsXzCaKTkA0Qw2w7HjJYlT/PadxCVmfsj8ZUAwU3LvO 9cujFui06/KJkv8obmnsKQTAONfWWqB8PO+iPe9A+kOyoscokF6mmLqkl9C2nALbz+SK jQdA== X-Forwarded-Encrypted: i=1; AFNElJ/x1kwsJRN4WVAwjDQIBJ3CW2LriNOkSLqpGvnwZwNuqgpqipPtxD4Y5t7pJeqyjAgfcJM5B3p41QMQaFg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx6q4xpHgZn2+Hh9ixOt8Xuk0b8yA619rurKZc7mZUsMo50juSq R6SZebw9ibMhqz6x1JzPe3+rLJmcIFKzSvcME7KMps57mvOf0RTYLmnoMx9U41tDblQZyFIdxV7 Ru59QIw== X-Received: from pfbmd16.prod.google.com ([2002:a05:6a00:7710:b0:82f:c134:e67c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:8d1:b0:82c:6aee:b21a with SMTP id d2e1a72fcca58-83f33f2a54fmr5839384b3a.45.1778872876956; Fri, 15 May 2026 12:21:16 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 15 May 2026 12:19:38 -0700 In-Reply-To: <20260515191942.1892718-1-seanjc@google.com> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260515191942.1892718-1-seanjc@google.com> X-Mailer: git-send-email 2.54.0.563.g4f69b47b94-goog Message-ID: <20260515191942.1892718-38-seanjc@google.com> Subject: [PATCH v3 37/41] x86/kvmclock: Use TSC for sched_clock if it's constant and non-stop From: Sean Christopherson To: Kiryl Shutsemau , Paolo Bonzini , Sean Christopherson , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Ajay Kaher , Alexey Makhalov , Jan Kiszka , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Juergen Gross , Daniel Lezcano , Thomas Gleixner , John Stultz Cc: Rick Edgecombe , Vitaly Kuznetsov , Broadcom internal kernel review list , Boris Ostrovsky , Stephen Boyd , x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Michael Kelley , Tom Lendacky , Nikunj A Dadhania , Thomas Gleixner , David Woodhouse Content-Type: text/plain; charset="UTF-8" Prefer the TSC over kvmclock for sched_clock if the TSC is constant, nonstop, and not marked unstable via command line. I.e. use the same criteria as tweaking the clocksource rating so that TSC is preferred over kvmclock. Per the below comment from native_sched_clock(), sched_clock is more tolerant of slop than clocksource; using TSC for clocksource but not sched_clock makes little to no sense, especially now that KVM CoCo guests with a trusted TSC use TSC, not kvmclock. /* * Fall back to jiffies if there's no TSC available: * ( But note that we still use it if the TSC is marked * unstable. We do this because unlike Time Of Day, * the scheduler clock tolerates small errors and it's * very important for it to be as fast as the platform * can achieve it. ) */ The only advantage of using kvmclock is that doing so allows for early and common detection of PVCLOCK_GUEST_STOPPED, but that code has been broken for over two years with nary a complaint, i.e. it can't be _that_ valuable. And as above, certain types of KVM guests are losing the functionality regardless, i.e. acknowledging PVCLOCK_GUEST_STOPPED needs to be decoupled from sched_clock() no matter what. Link: https://lore.kernel.org/all/Z4hDK27OV7wK572A@google.com Signed-off-by: Sean Christopherson --- arch/x86/kernel/kvmclock.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index abcc5b36ea1d..0578bc448b1b 100644 --- a/arch/x86/kernel/kvmclock.c +++ b/arch/x86/kernel/kvmclock.c @@ -416,22 +416,22 @@ void __init kvmclock_init(void) } /* - * X86_FEATURE_NONSTOP_TSC is TSC runs at constant rate - * with P/T states and does not stop in deep C-states. - * - * Invariant TSC exposed by host means kvmclock is not necessary: - * can use TSC as clocksource. - * + * If the TSC counts at a constant frequency across P/T states, counts + * in deep C-states, and the TSC hasn't been marked unstable, prefer + * the TSC over kvmclock for sched_clock and drop kvmclock's rating so + * that TSC is chosen as the clocksource. Note, the TSC unstable check + * exists purely to honor the TSC being marked unstable via command + * line, any runtime detection of an unstable will happen after this. */ if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) && !check_tsc_unstable()) { kvm_clock.rating = 299; tsc_properties = TSC_FREQ_KNOWN_AND_RELIABLE; + } else { + kvm_sched_clock_init(stable); } - kvm_sched_clock_init(stable); - tsc_register_calibration_routines(kvm_get_tsc_khz, kvm_get_tsc_khz, tsc_properties); -- 2.54.0.563.g4f69b47b94-goog