From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 132EF42D6F0 for ; Wed, 1 Jul 2026 19:33:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782934409; cv=none; b=Q35WR2IpfXl81M/GHUALHnVcFOUazDBWs/uLhQ9cC8vIb7ybiC+vbwu+9hL9dzuPIuJoyByJAUwOS7k9+Q8VN/yBhEu4Int+4cHTPM+QoB4FKHGC7aJLBB09f7/lg6ZWjZk1eAY7CCc7W9MdPZ/4EHbBkGkrThxlk26CqZT6F0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782934409; c=relaxed/simple; bh=1+k5bW4sotKJMM0NqHqr71EffqplV+UQXiw8XbSTW9o=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=gJJf8iGL3VUKnQ/OlG1oxmDDNWrA+uJHVRq/NzxhnWCV95KX+P2n0VsiGSzXS3CaS5TjKypK5TBVyo9pBzS6Ez765rgsUAODrOFU6t+e0hNyQ6Xp76xAerpCtluc9+DZeaWpXne3QRM/94cJ8C87/HeIwHa0LftAdBy1D2XrbV0= 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=HjwYuf2F; arc=none smtp.client-ip=209.85.216.73 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="HjwYuf2F" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-37e24235ce1so1374973a91.0 for ; Wed, 01 Jul 2026 12:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782934405; x=1783539205; darn=lists.linux.dev; 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=sbysuOQKV7W7YbruNHYRSyCV0jaRsBQX5EoVXm1Gq/A=; b=HjwYuf2FjNclAg3BIvwoRmHRN9P7x5+tn0eErWB6exCjXF7R6hZsVCH1f3dTtn1kzk JwUBbljxlJwfAlloTU463Hq8RJoYh+FHWOqLuMZZgflfj9TiNomZ9Le2ZwE38zUnwDYo uETS2+rJkRlfHGf/DZ+CokJNqzic7lLaaAeIT7XxcsWIeqvjDK40GA8ib9sRCbt/HlvO U/oVc3RkBIUXl8zPEM5Nx0AwjaNr+KLNvEXEbKRPfRfO6qLvpJAgDbNLisoSanzkfSQO RaGaetPzfBLJAnhK8Z8WzJusDLDWgeNdoaKp+uwUXhINha+lfdjNVAGVKm35/UpjTmco Axtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782934405; x=1783539205; 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=sbysuOQKV7W7YbruNHYRSyCV0jaRsBQX5EoVXm1Gq/A=; b=p+1Uljuvt4E52/yiAYIZfeGB52nb31B5+zvhqlO3oBRKDSASKpETXu4lbnClGW+UNL +wmmKHIxoYOiigN4CulLXCKFZR2yjdu14B4JMrY9KS3mu7ilDW2Y2Ej0eH8Wnn78eJJJ nmszHTDlkdta/QAkKDdeOsx2EmNKWK40Y5v26+DbyMIt5KWGj75ucH62TloDe8EgUUcb +jt78i+X53Op+zaNGAd2kNOvmHSsQKa1MObuTvW7xCiJNotQgOq7iknXVeh3kCsHi0aU OEZsyqF5a12nqvNe2zLi1Edbi8xMrb+Jso/tmJhHM6+547q9KA1IkRzODDoNpx4RNN7k lPrg== X-Forwarded-Encrypted: i=1; AHgh+Ro2IKiY84H7yvxpGH7jgkeVQqgpyDhtA7A9JLrkC7XnD73LAk34h29/1QDMSlxePlfiKDrLVyPPNRyWGwakFQ==@lists.linux.dev X-Gm-Message-State: AOJu0Yz4Pj4HELoJtgvPUUpTjPIwJhPaLr3xAIAI0xBnyVUASxuMfNi1 AN8rlMq5dVUL6UxRi4S/oCDnQghwUsV+xrsam0vNtRpCLoE5RaWP6KxlVcDsdizHZd282gf5B9i KoA9fmg== X-Received: from pjbbf15.prod.google.com ([2002:a17:90b:b0f:b0:37d:e898:7cd8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2886:b0:36a:f612:e6a3 with SMTP id 98e67ed59e1d1-380aa18d2b1mr3062418a91.17.1782934404832; Wed, 01 Jul 2026 12:33:24 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 1 Jul 2026 12:32:09 -0700 In-Reply-To: <20260701193212.749551-1-seanjc@google.com> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260701193212.749551-1-seanjc@google.com> X-Mailer: git-send-email 2.55.0.rc0.799.gd6f94ed593-goog Message-ID: <20260701193212.749551-49-seanjc@google.com> Subject: [PATCH v5 48/51] x86/kvmclock: Use TSC for sched_clock if it's constant and non-stop From: Sean Christopherson To: Jonathan Corbet , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Kiryl Shutsemau , Rick Edgecombe , Sean Christopherson , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Ajay Kaher , Alexey Makhalov , Jan Kiszka , Andy Lutomirski , Peter Zijlstra , Juergen Gross , Daniel Lezcano , John Stultz Cc: Shuah Khan , "H. Peter Anvin" , Vitaly Kuznetsov , Broadcom internal kernel review list , Boris Ostrovsky , Stephen Boyd , linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, Tom Lendacky , Nikunj A Dadhania , David Woodhouse , David Woodhouse , Michael Kelley , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Prefer the TSC over kvmclock for sched_clock if the TSC is constant and nonstop. 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 Reviewed-by: David Woodhouse Signed-off-by: Sean Christopherson --- arch/x86/kernel/kvmclock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c index 22e8855fcd4d..bc98ebb8587d 100644 --- a/arch/x86/kernel/kvmclock.c +++ b/arch/x86/kernel/kvmclock.c @@ -396,7 +396,6 @@ void __init kvmclock_init(bool prefer_tsc) PVCLOCK_TSC_STABLE_BIT; } - kvm_sched_clock_init(stable); if (!x86_init.hyper.get_tsc_khz) x86_init.hyper.get_tsc_khz = kvmclock_get_tsc_khz; @@ -416,6 +415,8 @@ void __init kvmclock_init(bool prefer_tsc) */ if (prefer_tsc) kvm_clock.rating = 299; + else + kvm_sched_clock_init(stable); clocksource_register_hz(&kvm_clock, NSEC_PER_SEC); pv_info.name = "KVM"; -- 2.55.0.rc0.799.gd6f94ed593-goog