NetBSD Problem Report #59437

From www@netbsd.org  Thu May 22 01:26:29 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 3FE661A923C
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 22 May 2025 01:26:29 +0000 (UTC)
Message-Id: <20250522012627.DC3421A923E@mollari.NetBSD.org>
Date: Thu, 22 May 2025 01:26:27 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: Xen time stability
X-Send-Pr-Version: www-1.0

>Number:         59437
>Category:       port-xen
>Synopsis:       Xen time stability
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-xen-maintainer
>State:          pending-pullups
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 22 01:30:00 +0000 2025
>Closed-Date:    
>Last-Modified:  Fri Oct 03 10:00:02 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
XenBSD Time's Up LLC
>Environment:
>Description:
NetBSD has trouble with timekeeping on Xen:

https://mail-index.netbsd.org/port-xen/2024/02/01/msg010525.html
https://mail-index.netbsd.org/port-xen/2024/06/20/msg010573.html
https://mail-index.netbsd.org/port-xen/2024/06/23/msg010599.html
https://mail-index.netbsd.org/tech-kern/2025/04/03/msg030310.html

Symptoms:

- `ntpq -np' shows offsets in the thousands (units of milliseconds, so offsets of multiple seconds)
- gettimeofday(3) returns the same result hundreds of times consecutively
- `vmstat -e | grep -w -e tsc -e systime -e hardclock -e timecounter' turns up various nonzero counts

Someone should draw up the matrix of what configurations and versions are affected like I requested at https://mail-index.netbsd.org/port-xen/2024/06/23/msg010599.html but it hasn't been drawn up yet as far as I know.
>How-To-Repeat:
unclear, but heavier load and more vCPUs may raise the probability
>Fix:
Yes, please!

>Release-Note:

>Audit-Trail:
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59437 CVS commit: src/sys/arch/xen/xen
Date: Thu, 22 May 2025 12:08:57 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Thu May 22 12:08:57 UTC 2025

 Modified Files:
 	src/sys/arch/xen/xen: xen_clock.c

 Log Message:
 xen: Use ordered rdtsc() function, rather than inline rdtsc asm.

 This will issue either lfence, mfence, or cpuid before the rdtsc
 instruction, depending on the CPU identification, in order to prevent
 reordering with respect to surrounding loads -- particularly those
 used to query the host's systime parameters.

 May help with:

 PR port-xen/59437: Xen time stability


 To generate a diff of this commit:
 cvs rdiff -u -r1.21 -r1.22 src/sys/arch/xen/xen/xen_clock.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 02 Oct 2025 12:47:21 +0000
State-Changed-Why:
pullup-10 #1170
no pullup-9 because pullup-9 doesn't calibrate lfence/mfence/&c. for rdtsc
(could pull that logic up and then apply this but probably not worth it)

doesn't fix the whole problem, so this should go back to open when pullup done


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59437 CVS commit: [netbsd-10] src/sys/arch/xen/xen
Date: Fri, 3 Oct 2025 09:58:44 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Fri Oct  3 09:58:44 UTC 2025

 Modified Files:
 	src/sys/arch/xen/xen [netbsd-10]: xen_clock.c

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1170):

 	sys/arch/xen/xen/xen_clock.c: revision 1.22

 xen: Use ordered rdtsc() function, rather than inline rdtsc asm.

 This will issue either lfence, mfence, or cpuid before the rdtsc
 instruction, depending on the CPU identification, in order to prevent
 reordering with respect to surrounding loads -- particularly those
 used to query the host's systime parameters.

 May help with:
 PR port-xen/59437: Xen time stability


 To generate a diff of this commit:
 cvs rdiff -u -r1.8.18.2 -r1.8.18.3 src/sys/arch/xen/xen/xen_clock.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search