Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3543689pxb; Mon, 4 Apr 2022 20:39:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZHg8SjsRmA4rirFZNx0pyvUIFqe3jeENvgnECjtYLpOt2BW9dsmbc2+1hkiPN3HuUxtEq X-Received: by 2002:a05:6a00:2d0:b0:4f4:1f34:e39d with SMTP id b16-20020a056a0002d000b004f41f34e39dmr1622115pft.14.1649129954418; Mon, 04 Apr 2022 20:39:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649129954; cv=none; d=google.com; s=arc-20160816; b=C2SUwAp3Dnz9iLJnyrF+7XB+43N9uVBit0l3dxfZLGm43zDBMryeWPQYVqHaWoaU1u 54MzeGQaDwSIbNLgo7N4L7xNAXWvSAUlvI0iqLsBGZCJAxktoFdoGN+SnDl+XWv0EIRO rFREFBVPUviEA7FbjBbxIWHxJLl3SEKIDhqh/hI+ybirYwo/bTFuONUl0EFnlvOi41XB YLf85dhddfqYOOzh1xSlWEGQEIGSNUTI+or1+zNHrv2m3n+ePOThI1g7Sh/vOHqvdxBg yluHzfKQSEiddvHX6ijHh8Gl6E4pVZd5PDC8qo2UN6xJJsLUQShT3JTxNyFV0d8YVp1J M11g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=aV0m0c+aJi/BzLPiLyQXOexC2EcW7rGlsZ0QrykO0QQ=; b=DUNSEtsrXdO0KNtCcA3swaXtYaaOdwLTheMEa7uuHqU5y2tcdQO/jOX646qOjkRIHx htLJB4tUiY5gdhrSAykrwQhjZSIzVd0xulCu41vPWFkGHgA6ZrNH4o2yjrHrtUt8mBxW 7fol4uNObIZcoB60PCpPNtZLdv9NaTHKe0UODFQetqqdHC6DzGo7HVJxeCbe7ObQc1K/ Y03WF5HFS7YS4oby6HWdRMmLSgg8AEFAOqyscvwxSX2tZUp1/2Md26Sx3yclkifJJ8r1 P/ow+GIpfPhLo4C0ivwKDXcEUyqnq1oVIxkbuiGyWQnvN3W8RXaWGNgQsloyf1jqwGRs oHSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wXbN1yWc; dkim=neutral (no key) header.i=@linutronix.de; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id i17-20020a170902c95100b00153b2d1640dsi11791619pla.21.2022.04.04.20.39.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 20:39:14 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=wXbN1yWc; dkim=neutral (no key) header.i=@linutronix.de; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C4D352B81A4; Mon, 4 Apr 2022 18:58:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229562AbiDECAD (ORCPT + 99 others); Mon, 4 Apr 2022 22:00:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbiDEB76 (ORCPT ); Mon, 4 Apr 2022 21:59:58 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4420B23DEBA; Mon, 4 Apr 2022 18:16:08 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649119625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aV0m0c+aJi/BzLPiLyQXOexC2EcW7rGlsZ0QrykO0QQ=; b=wXbN1yWcRjL6xdtvVkJQUtT7RCNzbFW+da7HgBVma1tDsSplKWtoSbt+e/Chg0JxIFceGh QWe+d8QblE7GlXHwUSm3Zk1WJsvCHtxEx3zLcD4QFQAiPUBcNl6OcNrHciPGSvWjVWs4q9 slH7CJusSJj8nWSnRwpWe8pJpqQLW41z9+eD3BBfsYl9T3i/r/jo1btucqFGA71IzK5vtt ypGXWHMN9oIYI+JlprBvAbLJ/1Aw/6Zb69io4RBVh7buKrWCqHf3QRGyWPNFoF3J9Q+3Kk VCUnH09H8y1QrKKdMiJfg7prFuOQUIGQ7QRVdrNyez94Mcg05JTFW124rdiGSA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649119625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aV0m0c+aJi/BzLPiLyQXOexC2EcW7rGlsZ0QrykO0QQ=; b=PvN12likTNzhXL9Xm1SPkolIgSvAcAahJC+d5EPzfPXQm0d0tXbYPkFJZ9klQVyrWNnXfr c2PxWRVqcmp/lSAQ== To: Mike Travis , Borislav Petkov , Ingo Molnar , Steve Wahl , x86@kernel.org Cc: Mike Travis , Dimitri Sivanich , Andy Shevchenko , Darren Hart , "H. Peter Anvin" , Russ Anderson , linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org Subject: Re: [PATCH v3 2/3] x86/platform/uv: Update TSC sync state for UV5 In-Reply-To: <20220404174111.262414-3-mike.travis@hpe.com> References: <20220404174111.262414-1-mike.travis@hpe.com> <20220404174111.262414-3-mike.travis@hpe.com> Date: Tue, 05 Apr 2022 02:47:04 +0200 Message-ID: <87zgl02w6v.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mike, On Mon, Apr 04 2022 at 12:41, Mike Travis wrote: > Update to not check TSC sync state for uv5+ as it is not available. > It is assumed that TSC will always be in sync for multiple chassis and > will pass the tests for the kernel to accept it as the clocksource. > To disable this check use the kernel start options tsc=reliable > clocksource=tsc. ... > --- > v2: Update patch description to be more explanatory. after reading the above word salad, I have no urge to go back to V1 to figure out how bad that changelog was. Let me walk through it: > Update to not check TSC sync state for uv5+ as it is not available. That's not a sentence and it does not provide any information about the background and the why. See: https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog for further explanation. > It is assumed that TSC will always be in sync for multiple chassis and > will pass the tests for the kernel to accept it as the clocksource. "It is assumed" is a real convincing technical argument - NOT! Either the hardware guarantees something or not. If the hardware cannot guarantee it but does not provide a mechanism to verify it then spell it out: "UV5 gave up on providing an interface which allows to query the TSC synchronization state. The hardware/firmware specification defines that TSC is synchronized accross multiple chassis, but there is neither a guarantee nor a validation mechanism. This leaves the kernel with the only option to assume that TSC is synchronized and TSC_ADJUST might be different between sockets due to UV5+ firmware synchronization." > To disable this check use the kernel start options tsc=reliable > clocksource=tsc. So now it get's really confusing. Which check? The one in your explanatory description above: "Update to not check TSC sync state for uv5+ as it is not available." or what? I can assume what are you trying to tell me here, but that's not a qualification for 'explanatory' > Signed-off-by: Mike Travis > Reviewed-by: Dimitri Sivanich > Reviewed-by: Steve Wahl Impressive list of Reviewed-by tags. Just for clarification: Reviewed-by tags include the changelog part. > --- > arch/x86/kernel/apic/x2apic_uv_x.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c > index f5a48e66e4f5..387d6533549a 100644 > --- a/arch/x86/kernel/apic/x2apic_uv_x.c > +++ b/arch/x86/kernel/apic/x2apic_uv_x.c > @@ -199,10 +199,16 @@ static void __init uv_tsc_check_sync(void) > int mmr_shift; > char *state; > > - /* Different returns from different UV BIOS versions */ > + /* UV5+, sync state from bios not available, assumed valid */ > + if (!is_uv(UV2|UV3|UV4)) { > + pr_debug("UV: TSC sync state for UV5+ assumed valid\n"); UV advertises its version all over the place and the call here: > + mark_tsc_async_resets("UV5+"); emits the reason at info level. So you surely need the pr_debug() above to figure out that your code works as expected. You just failed to add the obviuos counterpart: pr_debug("After calling hello_world()!\n"); Seriously. Neither the changelog nor the comment above the condition qualify for explanatory or useful. Please try again. > + > + /* UV2,3,4, UV BIOS TSC sync state available */ > mmr = uv_early_read_mmr(UVH_TSC_SYNC_MMR); > - mmr_shift = > - is_uv2_hub() ? UVH_TSC_SYNC_SHIFT_UV2K : UVH_TSC_SYNC_SHIFT; > + mmr_shift = is_uv2_hub() ? UVH_TSC_SYNC_SHIFT_UV2K : UVH_TSC_SYNC_SHIFT; How is this change related to the problem which this patch tries to solve? Documentation/process/* applies to UV too. You definitely should know that by now. Thanks, tglx