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.133.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 588D43D45F2 for ; Mon, 25 May 2026 08:09:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779696552; cv=none; b=BHUvkQ0qZYB0CfN/rCwi9SEcf4BbL9KAAXXBikYzoX7k6GebsT3R7uEo+V3zGUJTX89/QePmBksa28BPjKzQ71uLVzmkjTCBtHfuMFjxMpudD4hoqDQbOjmDpTMTQlK4pip75HR24iI644L0jT+VqY7bumHRRHsPS4oUBVHmh94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779696552; c=relaxed/simple; bh=/WvNqkdhp5mg/zTyGFklzcjNNCmKhbszW8WDUqEVzVE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OT4HjEMH/wwKnyNjMAoS9AJ9OCjtCzQb/1KM49eChwy6hMnNAZcsPyKxmt7Sq4jvnSZqLwn0Nu3su4aljBRreVbZGd+uq6QGiCkAgPy1VxcCPoy2XTjsnYRCKeOqG4oIsne17HVz1C/jqeqX80+iJf1Vbbf1iDaWBOBc46SJt+A= 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=bEFScv12; arc=none smtp.client-ip=170.10.133.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="bEFScv12" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779696549; 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=Y9c+pd13aO7hTGKF9Yn8rPzOpCMzo5dQGOH90CkhUZ8=; b=bEFScv12ZiFJ64wo0EC1IFBYipMq1NbuG7MRZ2CTijuE4D+bYGWuaWcGMe4cCTLDDuEr8e zRDwrkzs2HlDgAGjOMN2ILGd5fH48jbqFGK/Yb2l8MJ6qOj97BMd+stKhImDXjFtIHx+rL 6rk1i9OFPzAf22Jd3D90SfNLsPxf6Lg= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-292-6y2yHC0MNyG8rgx4lxLY-A-1; Mon, 25 May 2026 04:09:03 -0400 X-MC-Unique: 6y2yHC0MNyG8rgx4lxLY-A-1 X-Mimecast-MFC-AGG-ID: 6y2yHC0MNyG8rgx4lxLY-A_1779696541 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9E5E2195609F; Mon, 25 May 2026 08:08:59 +0000 (UTC) Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EAD7A3002D2D; Mon, 25 May 2026 08:08:53 +0000 (UTC) Date: Mon, 25 May 2026 10:08:51 +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, Marcelo Tosatti 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> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@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: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 On Thu, May 21, 2026 at 10:54:41AM +0100, David Woodhouse wrote: > On Thu, 2026-05-21 at 08:35 +0200, Miroslav Lichvar wrote: > > Ok, but I don't see why the phase corrections of the guest need to be > > in the kernel. > > I'm not sure I understand.  > > There are no 'phase corrections' as such, except of course that the > phase of the guest kernel's clock does get corrected, and naturally > that does have to take effect inside the guest kernel. I'm referring to these parts of the patches: delta_ns = timespec64_to_ns(&vmtime) - timespec64_to_ns(&now); if (delta_ns > 100000000 || delta_ns < -100000000) do_settimeofday64(&vmtime); ... /* Compute phase offset at cycle_last and set time_offset to slew */ delta = tk->tkr_mono.cycle_last - ref->counter_value; ref_frac = mul_u64_u64_shr(delta, ref->period_frac_sec, ref->period_shift) + ref->time_frac_sec; ref_err = (s64)mul_u64_u64_shr(ref_frac, (u64)NSEC_PER_SEC << tk->tkr_mono.shift, 64) - (s64)tk->tkr_mono.xtime_nsec; ntp_set_time_offset(tk->id, ref_err >> tk->tkr_mono.shift); > I think the key here is that this is not a feedback loop based on > corrections to the existing clock output; this is a feedforward design > as described in https://dl.acm.org/doi/pdf/10.1109/TNET.2011.2158443 There might be a disagreement on terminology. As the guest clock cannot be updated synchronously with the host, the tracking cannot be perfect and there has to be some way to correct for the errors due to the delay. That's what the code shown above seems to be doing. It's a feedback loop. It doesn't matter if the offset is calculated directly or measured. > It seems that when Julien et al lamented that, "Until now, however, > there has been a serious practical issue inhibiting feed-forward > approaches: a lack of kernel support", the basics were actually there > in the kernel's core timekeeping all along. >From my point of view, the only missing piece is software timestamping of packets using other clocks than CLOCK_REALTIME. > > > And TSC scaling is pretty much x86-specific; other architectures have a > > > *defined* counter frequency and don't need to support scaling. > > > > There can be a software fallback if hardware scaling and/or offset is > > not supported. > > Right. This *is* the software fallback, because the hardware scaling > and offset aren't sufficient even if we only care about x86 where the > former is supported. IMHO it's a solution done at a wrong layer. -- Miroslav Lichvar