Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Thu, 19 Oct 2023 08:51:55 +0200
From:   Andrew Jones <ajones@ventanamicro.com>
To:     Sean Christopherson <seanjc@google.com>
Cc:     Dongli Zhang <dongli.zhang@oracle.com>, kvm@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
        pbonzini@redhat.com, shuah@kernel.org, dwmw2@infradead.org,
        joe.jin@oracle.com
Subject: Re: [PATCH 1/1] selftests: KVM: add test to print boottime wallclock
Message-ID: <20231019-f96a45af9c235d89be644e67@orel>
References: <20231006175715.105517-1-dongli.zhang@oracle.com>
 <ZTA3W-f4sOX3LHfi@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZTA3W-f4sOX3LHfi@google.com>
Precedence: bulk

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@ventanamicro.com/

Thanks,
drew