From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 105FD4C77B7 for ; Tue, 19 May 2026 13:16:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779196586; cv=none; b=eAzS/Rbz/EkNvA408ymdergV+PVfS/GEAIcqGPoSjjxyEeGmLRlH+GJtmnAxLpQeoN5egynC8l91F1BQRil676Z/Oc0H7QNwFY9h9wNApde+vRBZqGVaTSlzimXBJIWTU5dDtN3jWmTnQiOFshol3eqMVMrsRjlMFyRD/HyPgn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779196586; c=relaxed/simple; bh=/JwDV190BFB6COjp7GTrmH0KES6R/v27u/f51aHvIr8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LasVQ1p5Ue0lKK/svmdxJFcJXVQQ+VdwKvW0WkDpWhXlC56E+cyBxVB5CcS2jU11UWaVkTGVbst2jJF+5w3mbND3Yr0ZZIq+ihdFOa2k8tsJZRGh21vXj2UL2kM+/2AsO1hD6Ax7KGRBYT32yX2zH8LLVRrPYP6dtT+SyowSKb8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Vf5FywKn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Vf5FywKn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779196583; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BZDbazHPfVgEvVc9e+fVmeI5gyNuU4JBjiY2Y0yaBdg=; b=Vf5FywKnUKrjy5J5MUw9GvNypR+NfyjWPpekhAjuAw6u9Dy2dykCYtPaE5rK2HjVvpScNS SRpRP3ctPTYAuo2+xoUXQTZhN8GTuf270CFN01kM8qdRxJeLZ5moLbKhpBbZUvD7PHvh5U BrPgDfGjqSpVf3XQ1Rf7pDlclQ/RKo8= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-443-Z81jnAv7My6subLUA2282w-1; Tue, 19 May 2026 09:16:20 -0400 X-MC-Unique: Z81jnAv7My6subLUA2282w-1 X-Mimecast-MFC-AGG-ID: Z81jnAv7My6subLUA2282w_1779196577 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 71E31180061E; Tue, 19 May 2026 13:16:16 +0000 (UTC) Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5ADDB1955D84; Tue, 19 May 2026 13:16:10 +0000 (UTC) Date: Tue, 19 May 2026 15:16:08 +0200 From: Miroslav Lichvar To: David Woodhouse Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Thomas Gleixner , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock Message-ID: References: <20260517220326.4625-1-dwmw2@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260517220326.4625-1-dwmw2@infradead.org> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 On Sun, May 17, 2026 at 10:25:37PM +0100, David Woodhouse wrote: > The vmclock device (https://uapi-group.org/specifications/specs/vmclock/) > provides a shared memory page containing a linear time function: > time = base + (counter - counter_value) × period. The guest can read > this at any time to determine the hypervisor's view of the current time, > without a VM exit. That sounds nice. > The existing ptp_vmclock driver already exposes this as a PTP clock for > userspace consumers (phc2sys, chrony). This series adds kernel-internal > consumption: the tick mechanism can clamp directly to the vmclock > reference, eliminating the need for NTP to discipline the guest clock. I'm not very familiar with the VM timekeeping and other code. If I understand this idea correctly, by loading the ptp_vmclock module the guest kernel is giving the host control of its clock. Changes in the host's REALTIME/MONOTONIC clock frequency are mirrored to the guest's clock. Differences larger than 100 milliseconds are corrected by step, whether the guest applications like it or not. Smaller steps and errors accumulated due to a delay in the frequency update (is there a limit to this delay?) are corrected by the kernel NTP PLL (with the default time constant?). When the guest is migrated to a different host, the frequency offset between the two hosts is injected to the NTP frequency (assuming REALTIME clocks of the hosts have zero frequency error at that moment?). Have you considered a different approach that would address the problem with frequency step by adjusting the guest's clocksource frequency to match the original host? That would correct all system clocks, i.e. not only REALTIME/MONOTONIC, but also MONOTONIC_RAW and AUX clocks. The guest would still be in control of its clock and follow its own preferences to stepping, maximum frequency errors, etc. It could still compare the stability and accuracy of the host's clock and use it for synchronization only when it's actually better than other available time sources (some VPS providers are known to have poorly synchronized host clocks). An AUX clock could be used to more accurately compare frequencies of the two hosts, ignoring phase corrections. There is a work in progress for chrony to support MONOTONIC_RAW as the main clock. It would be nice if that could be corrected in migrations. That seems to be a common cause of disruptions of public NTP servers. Polling for notifications about clock changes caused by migrations and system suspend+resume would be useful in any case. -- Miroslav Lichvar