Received-SPF: pass (google.com: domain of linux-kernel+bounces-151880-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 19 Apr 2024 19:43:43 +0100
From: David Woodhouse <dwmw2@infradead.org>
To: "Chen, Zide" <zide.chen@intel.com>, Jack Allister <jalliste@amazon.com>,
 Paolo Bonzini <pbonzini@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
 Sean Christopherson <seanjc@google.com>,
 Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
 Shuah Khan <shuah@kernel.org>
CC: Paul Durrant <paul@xen.org>, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
 linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_2/2=5D_KVM=3A_selftests=3A_Add_KVM/PV_c?=
 =?US-ASCII?Q?lock_selftest_to_prove_timer_drift_correction?=
User-Agent: K-9 Mail for Android
In-Reply-To: <17F1A2E9-6BAD-40E7-ACDD-B110CFC124B3@infradead.org>
References: <20240408220705.7637-1-jalliste@amazon.com> <20240408220705.7637-3-jalliste@amazon.com> <3664e8ec-1fa1-48c0-a80d-546b7f6cd671@intel.com> <17F1A2E9-6BAD-40E7-ACDD-B110CFC124B3@infradead.org>
Message-ID: <65FF4D51-05A8-42E0-9D07-6E42913CC75E@infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 19 April 2024 19:40:06 BST, David Woodhouse <dwmw2@infradead=2Eorg> wrot=
e:
>On 19 April 2024 18:13:16 BST, "Chen, Zide" <zide=2Echen@intel=2Ecom> wro=
te:
>>I'm wondering what's the underling theory that we definitely can achieve
>>=C2=B11ns accuracy? I tested it on a Sapphire Rapids @2100MHz TSC freque=
ncy,
>>and I can see delta_corrected=3D2 in ~2% cases=2E
>
>Hm=2E Thanks for testing!
>
>So the KVM clock is based on the guest TSC=2E Given a delta between the g=
uest TSC T and some reference point in time R, the KVM clock is expressed a=
s a(T-R)+r, where little r is the value of the KVM clock when the guest TSC=
 was R, and (a) is the rate of the guest TSC=2E
>
>When set the clock with KVM_SET_CLOCK_GUEST, we are changing the values o=
f R and r to a new point in time=2E Call the new ones Q and q respectively=
=2E
>
>But we calculate precisely (within 1ns at least) what the KVM clock would=
 have been with the *old* formula, and adjust our new offset (q) so that at=
 our new reference TSC value Q, the formulae give exactly the same result=
=2E
>
>And because the *rates* are the same, they should continue to give the sa=
me results, =C2=B11ns=2E
>
>Or such *was* my theory, at least=2E=20
>
>Would be interesting to see it disproven with actual numbers for the old+=
new pvclock structs, so I can understand where the logic goes wrong=2E
>
>Were you using frequency scaling?
>

Oh, also please could you test the updated version I posted yesterday, fro=
m https://git=2Einfradead=2Eorg/?p=3Dusers/dwmw2/linux=2Egit;a=3Dshortlog;h=
=3Drefs/heads/clocks