From: Thomas Gleixner <tglx@linutronix.de>
To: Feng Tang <feng.tang@intel.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@intel.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
paulmck@kernel.org, rui.zhang@intel.com, x86@kernel.org,
linux-kernel@vger.kernel.org
Cc: Feng Tang <feng.tang@intel.com>
Subject: Re: [PATCH RFC] x86/tsc: Make recalibration default on for TSC_KNOWN_FREQ cases
Date: Mon, 22 May 2023 10:14:08 +0200 [thread overview]
Message-ID: <87h6s4ye9b.ffs@tglx> (raw)
In-Reply-To: <20230522033018.1276836-1-feng.tang@intel.com>
On Mon, May 22 2023 at 11:30, Feng Tang wrote:
> Commit a7ec817d5542 ("x86/tsc: Add option to force frequency
> recalibration with HW timer") was added to handle cases that the
> firmware has bug and provides a wrong TSC frequency number, and it
> is optional given that this kind of firmware issue rarely happens
> (Paul reported once [1]).
>
> But Rui reported that some Sapphire Rapids platform met this issue
> again recently, and as firmware is also a kind of 'software' which
> can't be bug free, make the recalibration default on. When the
> values from firmware and HW timer's calibration have big gap,
> raise a warning and let vendor to check which side is broken.
Sure firmware can have bugs, but if firmware validation does not even
catch such a trivially to detect bug, then their validation is nothing
else than rubber stamping. Seriously.
Are any of these affected platforms shipping already or is this just
Intel internal muck?
> One downside is, many VMs also has X86_FEATURE_TSC_KNOWN_FREQ set,
> and they will also do this recalibration.
It's also pointless for those SoCs which lack legacy hardware.
So why do you force this on everyone?
Thanks,
tglx
next prev parent reply other threads:[~2023-05-22 8:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 3:30 [PATCH RFC] x86/tsc: Make recalibration default on for TSC_KNOWN_FREQ cases Feng Tang
2023-05-22 8:14 ` Thomas Gleixner [this message]
2023-05-22 8:47 ` Feng Tang
2023-05-22 11:49 ` Thomas Gleixner
2023-05-22 13:00 ` Feng Tang
2023-05-22 14:31 ` Thomas Gleixner
2023-05-22 15:20 ` Feng Tang
2023-05-22 16:11 ` Peter Zijlstra
2023-05-23 1:18 ` Feng Tang
2023-05-23 8:11 ` Peter Zijlstra
2023-05-23 14:31 ` Feng Tang
2023-06-02 18:29 ` Paul E. McKenney
2023-06-02 18:36 ` Dave Hansen
2023-06-02 19:08 ` Paul E. McKenney
2023-06-05 1:04 ` Feng Tang
2023-06-08 16:58 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6s4ye9b.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=feng.tang@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rui.zhang@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox