From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE220C00A98 for ; Fri, 20 Oct 2023 15:22:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377626AbjJTPW2 (ORCPT ); Fri, 20 Oct 2023 11:22:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377694AbjJTPWZ (ORCPT ); Fri, 20 Oct 2023 11:22:25 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47D37D73 for ; Fri, 20 Oct 2023 08:22:23 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a8ead739c3so12639857b3.3 for ; Fri, 20 Oct 2023 08:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697815342; x=1698420142; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=KeBN29hJ4LjkmlULAdi6wXvguRmPwY9ij6dOK18Our8=; b=kzHIdtfH2CVtn1JZPsuG8SO46dkMev2ofrsHDocgM3362Cyr0TK06sGE042I0JdZnE fnyhlEKOMsBLtuis21yUl5CM/TFSPolFMAvP3Ucdkn3i3Lev+lkatqkpaPA9bJxrVEJA IKuzqFe2je15oQdrwd9FTMGfgZP5NVXr4T1qs94UIAfivvaHdJI/srgHCOvZsMaHakPR w00cRWFNhHvezUG6weBOGCTUM+/IccucfidT4nLiS6tI9ooFW4EPV+JsfZmrqTDqpda8 K7FgNCA5X50/wh4S4bRqUp+XiYNXFX0vH28oCf2JqVB/6Elk53FsOmMdhwtCS+BPqXx4 IR+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697815342; x=1698420142; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KeBN29hJ4LjkmlULAdi6wXvguRmPwY9ij6dOK18Our8=; b=RPcKBxDEI2TU18SeVENnV0fWWfv0tk/lAgThFmMSAwjVlUCGN1inPEmuiWn/TynyUd MQzEr+w5NMfKS3TZXYL+o7v/ppHGQZQ13GrBPbAq4QuWg3QImTWMXaNxMYBrYzwbYsaV ryY4Bf+/FH6N39Az9JO8SvOYSIxXLKdZ+PUa5oDt8yTditz7lsG2yYHrARtQKmgVt8Yw JPttJH8qTvi33jIujLdYMWfJfN/9QpzMtTGtrihyWJGuGc8LzMdibYEzkwjlfrFbCc9X zKI1qLZ4W2KRxnF8t8f964lrw8EYOKCBOCt1avQwH6cGRgTebCTRtAHPw6oWHe7intag BmfA== X-Gm-Message-State: AOJu0Yw63PzUj/b/nhi9PPF26q9IGfEBcxjNKI2y2LOyKKLDUqMeQgmT pX46NZDAepv5usNMf/0QF72DLjt27ZU= X-Google-Smtp-Source: AGHT+IGJ8nVnX9/UbO2Yh1OQ/NK9Kx6ZKcxAld+bIeetVr1RVijF0J+1mwesfi/RqnFrlFaxlWSuOWUi13k= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a0d:d50f:0:b0:592:7a39:e4b4 with SMTP id x15-20020a0dd50f000000b005927a39e4b4mr51324ywd.6.1697815342159; Fri, 20 Oct 2023 08:22:22 -0700 (PDT) Date: Fri, 20 Oct 2023 08:22:20 -0700 In-Reply-To: Mime-Version: 1.0 References: <20231006175715.105517-1-dongli.zhang@oracle.com> <20231019-f96a45af9c235d89be644e67@orel> Message-ID: Subject: Re: [PATCH 1/1] selftests: KVM: add test to print boottime wallclock From: Sean Christopherson To: Dongli Zhang Cc: Andrew Jones , 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 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2023, Dongli Zhang wrote: > 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. Rather than pick an arbitrary time of 10 seconds, deliberately introduce a plausible bug in KVM (or re-introduce a previous bug) and see how low you can push the wait time while still reliably detecting the unwanted drift. Then add a reasonable buffer to give the test some margin for error. Given the drift that David reported with the xen_shinfo test, I assume/hope that a 10 second runtime would be overkill. I would also differentiate between total runtime and the periodic check time, e.g. to allow checking for drift every N (milli)seconds while having a total runtime of M seconds. Then there's no need to set an upper bound, e.g. the user could set the test to run in the background for multiple hours without having to worry about the test being useless if it's canceled early.