Received: by 2002:a9a:4c47:0:b029:116:c383:538 with SMTP id u7csp820701lko; Tue, 13 Jul 2021 10:50:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz05Mn+LIFQYnMnqOyHJdP9PQQykXMF7ABVBS0UgzOQb58Xn78rnG9C7O2GUBGYDENeAbv1 X-Received: by 2002:a17:906:b0c5:: with SMTP id bk5mr2688196ejb.428.1626198640057; Tue, 13 Jul 2021 10:50:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626198640; cv=none; d=google.com; s=arc-20160816; b=TvEru4raNVYOS3SutmBxVaEZSdCG9QF/eqJDfZJCG0zhhhyABxoitbqJsnzAbgNrhh SvRcqWZTehqf4khdJPJ+RljoXbCtiltYK6H3ezgiGj+kaP9FNgHTLlCQJGoEC0bru2Ud VH6FZPFH1EzXGO3dHT5jHIr2H2Yr7CsX5it4UZuh8vudfOPmoEkggIzDM3xyZEyLCGXS Wtv3UX9lxSKkfxV+fWETxNtQo+gnPDU4BMPfEr6wooNfxf6vTrtJArxVabx+VJPupjTy lxhKj3deSAhAFKCGkhBGvQFe/SfB2vBeKbNiH5OUK/Q/sWNtrr7AIXheZxPDLFVxWnDD jk0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:date:from:dkim-signature; bh=mkfpRgpeLPxUYp+ddTZkPNka6bB8ZGq5QWO32nx4iz0=; b=e/uXE3CxJY1ePkKacdWkCRDHbZZeTgnsLAf1Lvam4mQoTy8jzSl5JO2IfB/BToifMo +KAtJ/sNb9luO7i23RmL91zpZkDnJzxrQN7zLtuJJpnNYhlYQpz1T879M4Hy4oyjpJeI Hq0JfAtxnEoUZh9FiL66aEqHCKfrmLZLzog66jVU85DVn+gHBkpI54pCUCGF23x/dz44 6I5PD/QtK3MIf9eVzywwoKHEz3l1n9vmjoyNmpkobTCT7RSPtSliHSy+Tb4kkAZcVGqo YBsyp10hhH32zYKjan98LH07QEPlfq1CB61P39PTIG3PGTTvYJ25M4hWG1dHAEAK+OUh zcqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b=edC+uUrC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si11629571edr.43.2021.07.13.10.50.16; Tue, 13 Jul 2021 10:50:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b=edC+uUrC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229867AbhGMRvz (ORCPT + 99 others); Tue, 13 Jul 2021 13:51:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229555AbhGMRvz (ORCPT ); Tue, 13 Jul 2021 13:51:55 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07DE7C0613E9 for ; Tue, 13 Jul 2021 10:49:04 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id oj10-20020a17090b4d8ab0290172f77377ebso2624788pjb.0 for ; Tue, 13 Jul 2021 10:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anisinha-ca.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=mkfpRgpeLPxUYp+ddTZkPNka6bB8ZGq5QWO32nx4iz0=; b=edC+uUrC1ibal60WPRY84ZBLQ48kYRawi7D+gIF4wCdJuwZP0m5q/uuWjmHOWtUpdE 06YSilXhpiGlcb6XyD2iMRYLL87z+wfOxHXMUHX08Py7mdZdj5dM8CxAF2Sj5HgqhWkD itfGjjLC8XA3IDYkRuOAPUwYooUT3aXXSojtV6y7Vctx5w2b9kFUd5i7FaRg6j1HSwAQ IkV5tUP3PDpNdB8NOcja6zELBwjYaq+ORUHqTtTvhGee+R1z1Ds9LpUSEAea8Gwh3fdM SX/y/ShBo+ZdIxOYsOg7pIdz3XNP2rAahf1jtFmIMFgNm62pkvjN1+AQHucvUPlHZXAq zwIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=mkfpRgpeLPxUYp+ddTZkPNka6bB8ZGq5QWO32nx4iz0=; b=dkAWdaHWraL9s8XGeV1JANeUq4nMHzPZcCgUfbq6qIXqiQwhsVN8sjXex9tDs34DKZ XzaIEOrz59+QVftUG00fj0thX59DIM4g4K+Ni8MASyVVjwqhDnrvhGq+PL0C6zFdb4rj TlAv6cjc9Q9GSEG6/mSl0dmqCNYQVyiEv1FIJtWpuTdmeMj+pbDE3jGoqWX8XdYD+03c qUQ/F8wILmxPjyH+spgTbv2t6GuRuXYEDX6FoGFFANKcebnPG9yAqAkjDLidu1/xEJ/a 4v1uKYg3Rl0X5Bxd3uF4XFAqiDSzZDkd4ofa6BsUp6UR8611cw7PTeF2FOj0oAdn8WES GZcg== X-Gm-Message-State: AOAM532FwOw4zYIoLLrNtdgz7+stvfrH0ALDuFnIsGpJNCT2vPz1Axru ULrdANXaFMzV3nrpSG5b3/xIeg== X-Received: by 2002:a17:90a:420c:: with SMTP id o12mr5364656pjg.101.1626198544250; Tue, 13 Jul 2021 10:49:04 -0700 (PDT) Received: from anisinha-lenovo ([115.96.158.88]) by smtp.googlemail.com with ESMTPSA id f3sm12953271pfk.206.2021.07.13.10.48.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 10:49:03 -0700 (PDT) From: Ani Sinha X-Google-Original-From: Ani Sinha Date: Tue, 13 Jul 2021 23:18:46 +0530 (IST) X-X-Sender: anisinha@anisinha-lenovo To: Michael Kelley cc: Ani Sinha , "linux-kernel@vger.kernel.org" , "anirban.sinha@nokia.com" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , "H. Peter Anvin" , "linux-hyperv@vger.kernel.org" Subject: RE: [PATCH] Hyper-V: fix for unwanted manipulation of sched_clock when TSC marked unstable In-Reply-To: Message-ID: References: <20210713030522.1714803-1-ani@anisinha.ca> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Jul 2021, Michael Kelley wrote: > From: Ani Sinha Sent: Monday, July 12, 2021 8:05 PM > > > > Marking TSC as unstable has a side effect of marking sched_clock as > > unstable when TSC is still being used as the sched_clock. This is not > > desirable. Hyper-V ultimately uses a paravirtualized clock source that > > provides a stable scheduler clock even on systems without TscInvariant > > CPU capability. Hence, mark_tsc_unstable() call should be called _after_ > > scheduler clock has been changed to the paravirtualized clocksource. This > > will prevent any unwanted manipulation of the sched_clock. Only TSC will > > be correctly marked as unstable. > > > > Signed-off-by: Ani Sinha > > --- > > arch/x86/kernel/cpu/mshyperv.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 22f13343b5da..715458b7729a 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -370,8 +370,6 @@ static void __init ms_hyperv_init_platform(void) > > if (ms_hyperv.features & HV_ACCESS_TSC_INVARIANT) { > > wrmsrl(HV_X64_MSR_TSC_INVARIANT_CONTROL, 0x1); > > setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); > > - } else { > > - mark_tsc_unstable("running on Hyper-V"); > > } > > > > /* > > @@ -432,6 +430,12 @@ static void __init ms_hyperv_init_platform(void) > > /* Register Hyper-V specific clocksource */ > > hv_init_clocksource(); > > #endif > > + /* TSC should be marked as unstable only after Hyper-V > > + * clocksource has been initialized. This ensures that the > > + * stability of the sched_clock is not altered. > > + */ > > For multi-line comments like the above, the first comment line > should just be "/*". So: Hmm, checkpatch.pl in kernel tree did not complain : total: 0 errors, 0 warnings, 20 lines checked 0001-Hyper-V-fix-for-unwanted-manipulation-of-sched_clock.patch has no obvious style problems and is ready for submission. However, I do know from my experience of submitting Qemu patches last year that this is a requirement imposed by the Qemu community as checkpatch.pl in qemu tree would complain otherwise. I also took a peek at the Qemu git history. It seems they imported this check from the kernel's checkpatch.pl with this commit in Qemu tree: commit 8c06fbdf36bf4d4d486116200248730887a4d7d6 Author: Peter Maydell Date: Fri Dec 14 13:30:48 2018 +0000 scripts/checkpatch.pl: Enforce multiline comment syntax Which adds this rule: + # Block comments use /* on a line of its own + if ($rawline !~ m@^\+.*/\*.*\*/[ \t]*$@ && #inline /*...*/ + $rawline =~ m@^\+.*/\*\*?[ \t]*.+[ \t]*$@) { # /* or /** non-blank + WARN("Block comments use a leading /* on a separate line\n" . $herecurr); + } But in kernel there is no such rule. Hmm. strange! > > /* > * TSC should be marked as unstable only after Hyper-V > * clocksource has been initialized. This ensures that the > * stability of the sched_clock is not altered. > */ > > > > + if (!(ms_hyperv.features & HV_ACCESS_TSC_INVARIANT)) > > + mark_tsc_unstable("running on Hyper-V"); > > } > > > > static bool __init ms_hyperv_x2apic_available(void) > > -- > > 2.25.1 > > Modulo the comment format, > > Reviewed-by: Michael Kelley > Tested-by: Michael Kelley >