linux-kernel - Re: [PATCH 2/2] KVM: selftests: Add KVM/PV clock selftest to prove timer drift correction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 10 Apr 2024 10:15:29 +0000
From: "Allister, Jack" <jalliste@...zon.co.uk>
To: "dongli.zhang@...cle.com" <dongli.zhang@...cle.com>
CC: "corbet@....net" <corbet@....net>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "shuah@...nel.org" <shuah@...nel.org>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "mingo@...hat.com"
	<mingo@...hat.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "dwmw2@...radead.org"
	<dwmw2@...radead.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "hpa@...or.com" <hpa@...or.com>, "paul@....org"
	<paul@....org>, "bp@...en8.de" <bp@...en8.de>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"Allister, Jack" <jalliste@...zon.co.uk>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 2/2] KVM: selftests: Add KVM/PV clock selftest to prove
 timer drift correction

> AFAIR, I copied check_clocksource() from existing code during that >
time.

> The commit e440c5f2e ("KVM: selftests: Generalize check_clocksource()
> from kvm_clock_test") has introduced sys_clocksource_is_tsc(). Later
> it is renamed to sys_clocksource_is_based_on_tsc().
> Any chance to re-use sys_clocksource_is_based_on_tsc()?

Yes I'm more than happy to change it to that. I was using your original
mail as a reference and did not realise there was a utility present for
this.

> Is configure_scaled_tsc() anecessary? Or how about to make it an  >
option/arg?
> Then I will be able to test it on a VM/server without TSC scaling.

So if TSC scaling from 3GHz (host) -> 1.5GHz (guest) I do see a skew of
~3500ns after the update. Where as without scaling a delta can be seen
but is roughly ~180ns.

In V2 I've adjusted the test so that now by default scaling won't take
place, however if someone wants to test with it enabled they can pass
"-s/--scale-tsc" to induce the greater delta.


Thanks you for the feedback,
Jack Allister