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). 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://lore.kernel.org/all/20231011135610.122850-14-ajones@xxxxxxxxxxxxxxxx/ Thanks, drew
