Received-SPF: pass (google.com: domain of linux-kernel+bounces-177578-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [GIT pull] x86/timers for v6.10-rc1
References: 
 <171560454635.3871325.5773365584560034962.tglx@xen13.tec.linutronix.de>
Message-ID: 
 <171560455005.3871325.1102142666677911813.tglx@xen13.tec.linutronix.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 13 May 2024 14:50:02 +0200 (CEST)

Linus,

please pull the latest x86/timers branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-timers-2024-=
05-13

up to:  455f9075f144: x86/tsc: Trust initial offset in architectural TSC-adju=
st MSRs

A single update for the TSC synchronixation sanity checks:

  The sad state of TSC being notoriously non-sychronized for several
  decades caused the kernel to grow quite rigorous sanity checks to detect
  whether the TSC is valid to be used for timekeeping.

  The TSC ADJUST MSR provides the offset between the initial TSC value
  after hardware reset and later modifications. This allows to detect cases
  where firmware tampers with the TSC and also allows to correct the
  firmware induced damage by resetting the offset in a controlled way.

  The universal correct rule is that the TSC ADJUST value has to be
  consistent within all CPUs of a socket.

  The kernel further assumes that the TSC offset should be consistent
  between sockets. That's not really correct as systems with a huge number
  of sockets are not architecurally guaranteed to reset the per socket TSC
  base synchronously.

  In case that the per socket offset is not consistent the kernel resets it
  to the offset of the boot CPU and then does a synchronization check which
  corrects for the inter socket delays.

  That works most of the time, but it is suboptimal as the firmware has
  eventually better information about the per socket offset and on sane
  systems that offset should just work in the validation checks.

Thanks,

	tglx

------------------>
Daniel J Blueman (1):
      x86/tsc: Trust initial offset in architectural TSC-adjust MSRs


 arch/x86/kernel/tsc_sync.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/tsc_sync.c b/arch/x86/kernel/tsc_sync.c
index 1123ef3ccf90..4334033658ed 100644
--- a/arch/x86/kernel/tsc_sync.c
+++ b/arch/x86/kernel/tsc_sync.c
@@ -193,11 +193,9 @@ bool tsc_store_and_check_tsc_adjust(bool bootcpu)
 	cur->warned =3D false;
=20
 	/*
-	 * If a non-zero TSC value for socket 0 may be valid then the default
-	 * adjusted value cannot assumed to be zero either.
+	 * The default adjust value cannot be assumed to be zero on any socket.
 	 */
-	if (tsc_async_resets)
-		cur->adjusted =3D bootval;
+	cur->adjusted =3D bootval;
=20
 	/*
 	 * Check whether this CPU is the first in a package to come up. In