linux-kernel - Re: [PATCH 1/1] selftests: KVM: add test to print boottime wallclock

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]

Message-ID: <bbddbf1f-33c1-cdae-9e0a-a05403bf44bd@oracle.com>
Date:   Fri, 20 Oct 2023 07:39:00 -0700
From:   Dongli Zhang <dongli.zhang@...cle.com>
To:     Andrew Jones <ajones@...tanamicro.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, pbonzini@...hat.com,
        shuah@...nel.org, dwmw2@...radead.org, joe.jin@...cle.com
Subject: Re: [PATCH 1/1] selftests: KVM: add test to print boottime wallclock

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@ventanamicro.com/__;!!ACWV5N9M2RV99hQ!LuJ92LOR4jVJfhj8M0J9MUqP7520s259wSzAdAL1cV0zNrzVB2W0F_5gpEVX_SoHeKuivIt-VIVB6jaN5EuIKA$ 
> 
> Thanks,
> drew