Hi Sean and Andrew, On 10/18/23 23:51, Andrew Jones wrote: > On Wed, Oct 18, 2023 at 12:51:55PM -0700, Sean Christopherson wrote: >> On Fri, Oct 06, 2023, Dongli Zhang wrote: >>> As inspired by the discussion in [1], the boottime wallclock may drift due >>> to the fact that the masterclock (or host monotonic clock) and kvmclock are >>> calculated based on the algorithms in different domains. >>> >>> This is to introduce a testcase to print the boottime wallclock >>> periodically to help diagnose the wallclock drift issue in the future. >>> >>> The idea is to wrmsr the MSR_KVM_WALL_CLOCK_NEW, and read the boottime >>> wallclock nanoseconds immediately. >> >> This doesn't actually test anything of interest though. IIUC, it requires a human >> looking at the output for it to provide any value. And it requires a manual >> cancelation, which makes it even less suitable for selftests. >> >> I like the idea, e.g. I bet there are more utilities that could be written that >> utilize the selftests infrastructure, just not sure what to do with this (assuming >> it can't be massaged into an actual test). Thank you very much for the suggestion. Would that work if I turn it into a test: 1. Capture boottime_wallclock_01. 2. Wait for 10-second by default (configurable, e.g., max 60-second) 3. Capture boottime_wallclock_02. 4. Report error if drift. I have another pvclock vCPU hotplug test with the same flow. Thank you very much! Dongli Zhang > > Yes, there's definitely code overlap between selftests and [debug/test] > utilities. For example, I snuck a utility into [1]. For that one, without > any command line parameters it runs as a typical test. Given command line > input, it behaves as a utility (which developers may use for additional > platform-specific testing). It seems like we need a way to build and > organize these types of things separately, i.e. a utility should probably > be in tools/$DIR not tools/testing/selftests/$DIR. For [1], I don't have > much of an excuse for not just splitting the two functionalities into two > files, but, for KVM selftests, we'd need to find a way to share the > framework. > > [1] https://urldefense.com/v3/__https://lore.kernel.org/all/20231011135610.122850-14-ajones@xxxxxxxxxxxxxxxx/__;!!ACWV5N9M2RV99hQ!LuJ92LOR4jVJfhj8M0J9MUqP7520s259wSzAdAL1cV0zNrzVB2W0F_5gpEVX_SoHeKuivIt-VIVB6jaN5EuIKA$ > > Thanks, > drew
