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 97884CDB465 for ; Thu, 19 Oct 2023 06:52:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232797AbjJSGwH (ORCPT ); Thu, 19 Oct 2023 02:52:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232383AbjJSGwE (ORCPT ); Thu, 19 Oct 2023 02:52:04 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B2F411B for ; Wed, 18 Oct 2023 23:51:59 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-317c3ac7339so6509176f8f.0 for ; Wed, 18 Oct 2023 23:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1697698317; x=1698303117; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mw4Ufl/cOqWrZrf06coK8u2YQD70TRL1KhrXVtvZNrw=; b=nsUsNCHZFTEW7NrHc+xLEg94MIbZEvhG0XTqLEf4/mQVG826I9Zx6/dJjVJ2XTE1dK U4ezwvNwlGi70f4bRGI5jo5RvcFWCkzz8TFj0n/ymYdItVbq7H1cbm62uSaIaRarkYDe IoYLkzdC1sMQ+OXGGAULWL11HQ+0//3zL3A614dvTxMT2+Va2XUttM3PiyWdhK0i4XU3 OqlfQhVf7tBd/itKq5ScC8o/GDuCXzQapUoCjZgWPWKKPHMLnl1loQaQ3gLlFUJiQUvi ArgyVvSZaiXH/AxQAPrzH4LgarMhNNH1zNCtqfvPXtIsdE8KtA6nUEbtaVxGmaAizjXF sMpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697698317; x=1698303117; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mw4Ufl/cOqWrZrf06coK8u2YQD70TRL1KhrXVtvZNrw=; b=RaeNQ21uzWnVPQnfh4xvuCeNFhBa3Vvc4eCDk9Qbky0MGm3iOSVsTVIrlFvA6MuyUz rx5n5iTUD88qCOxFKVtSarUjpT/Whzi51EnciqwsYfYHWvbms3DEA+tJld9cMfqR7LNb gm5dRxKULglFrEefZYREVl5MgxbX67DG3k86G/BsgKb6zozYDTb+lz3GrAjjZ+jlNYrQ 4ZWLR7pIIBorD6WCqDTMTSIT1gFO2vwqOs7dKmalncZNVyT5V3uFXV/Wd8byormkHtiE NHUQyfjhYgW0CF/81uU9ALEGQzo5yHsmtArCjBk3KaZLxSjn+t8rEnVSKe1t7Xa0A/tR ykpw== X-Gm-Message-State: AOJu0Yz1s0hqGBA1tOY5qByALD3bfVeB2brPRRTYOzJUhTjXns2VJvFe xHmkU6mSOqKulU/pAD8Pda880A== X-Google-Smtp-Source: AGHT+IFGx0X/DCQzpamvzML5eVZXREJOW7/gfUas0fSutEbwJ26Qfuw+v6wfWgMQ1KlpLCIJu+0MUg== X-Received: by 2002:a5d:630d:0:b0:32d:87c8:b54e with SMTP id i13-20020a5d630d000000b0032d87c8b54emr860927wru.1.1697698317404; Wed, 18 Oct 2023 23:51:57 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id i3-20020a5d6303000000b0032db4e660d9sm3710915wru.56.2023.10.18.23.51.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 23:51:56 -0700 (PDT) Date: Thu, 19 Oct 2023 08:51:55 +0200 From: Andrew Jones To: Sean Christopherson Cc: Dongli Zhang , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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